TUGAS

MODEL DAN SISTEM INFORMASI

“SUKSES DAN KEGAGALAN SISTEM : SEBUAH IMPLEMENTASI”

DISUSUN OLEH :

Adhie Tri Wahyudi

Asih Winantu

Ari Muzakir

Agus Wahyu Widodo

Putu Indah Ciptayani

S2 ILMU KOMPUTER

UNIVERSITAS GADJAH MADA

2010

BAB 14

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 file 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 profil 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 fitur-fitur teknis sistem informasi tetapi

sumber nonteknis juga. Pada kenyataannya, sebagian besar masalah berasal dari faktor organisasi.

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

Sistem

Informasi Desain

Data

Operasi

Biaya

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 konflik.

Data

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.

Biaya

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.

Operasi

Sistem ini tidak berjalan dengan baik. Informasi tidak diberikan secara tepat waktu dan

efisien 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 finansial kepada organisasi, baik dengan mengurangi biaya atau meningkatkan

penjualan atau keuntungan.

Ukuran

kesuksesan

sistem informasi

Penggunaan

sistem level

tinggi

Kepuasan

pengguna

pada sistem

Perilaku

menguntungkan

dari fungsi

sistem

Tercapainya

tujuan

sistem

Pembayaran

finansial

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 pendefinisian

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 fitur 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.

PENDEKATAN TAHAP IMPLEMENTASI

Adopsi Manajemen Rutinitas

Peranan Pelaku XXXX XXXX

Strategi XXXX

Faktor Organisasi XXXX XXXX

Gambar 14.3. Tahap Pendekatan 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

Peranan Pelaku

- Product champion

- Wiraswasta

birokratis

- Penjaga gate

Perilaku inovatif

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 mendefinisi ulang konfigurasi, interaksi,

aktifitas, 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

fleksibelitas 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 :

Konflik 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

pengaruh

pengguna

Dukungan

manajemen

Level

kekomplekan/

resiko

Manajemen

proses

implementasi

PENGHASILAN

IMPLEMENTASI

Design Biaya

Data Operasi

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 efisiensi 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 yang saya butuhkan untuk pekerjaan saya?

Seberapa banyak penyimpanan yang akan digunakan oleh file master?

Seberapa cepat saya dapat mengakses data itu? Seberapa banyak baris program yang akan digunakan untuk melakukan fungsi ini?

Seberapa mudah saya mendapatkan data? Bagaimana kita bisa menurunkan waktu CPU saat kita menjalankan sistem?

Seberapa banyak dukungan administrasi(tulis menulis) yang saya butuhkan untuk memasukkan data ke dalam sistem?

Apakah cara paling efisien untuk menyimpan potongan data ini?

Bagaimana operasi sistem sesuai untuk jadwal bisnis harian saya?

Sistem manajemen basis data apa yang akan kita pergunakan?

Tabel 2. Gap Komunikasi 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 mengidentifikasi tiga dimensi kunci yang mempengaruhi level resiko

perlindungan (McFarlan, 1981).

Ukuran Project

Besarnya suatu proyek diidentifikasikan 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 didefinisikan 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

didefinisikan, 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 Structure Project Technology

Level Project Size Degree Of Risk

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).

Poor Project

Management

Cost overruns

Time slippage

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

proyek

Level teknologi

proyek

Ukuran

proyek

Derajat resiko Alat manajemen 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 efisiensi 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.

Konflik 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.

Studi kasus - apa yang salah di FoxMeyer?

FoxMeyer Drug Co dari Carrollton, Texas, adalah unit utama FoxMeyer Health Corporation.

Pada waktu itu FoxMeyer adalah grosir obat keempat terbesar di Amerika Serikat dengan penjualan

pada tahun 1995 sebesar $5,1 miliar. Industri grosir obat sudah berlangsung melalui konsolidasi

cepat, dan pada awal dan pertengahan 1990-an, manajemen FoxMeyer dihadapkan pada

pertanyaan tentang bagaimana mereka akan bersaing dengan kompetitor yang lebih besar untuk

menjamin kelangsungan hidup mereka.

Obat FoxMeyer didistribusikan melalui sistem gudang di bidang pelanggan utama

Perusahaan. Setiap hari perusahaan diisi pesanan dari ribuan apotek dan rumah sakit, pengiriman

sampai dengan 500.000 item dalam pesanan ini. Menjaga kontrol dengan ketat terhadap persediaan

sangat penting untuk industri ini karena biaya mempertahankan persediaan untuk mendukung

pengiriman sehari-hari begitu besar. Pada saat yang sama, seluruh industri bersaing dengan operasi

pada margin keuntungan rendah. Kualitas layanan pelanggan, termasuk kecepatan, keakuratan

pengiriman pesanan, merupakan kunci untuk kompetisi. FoxMeyer percaya hal itu akan

menawarkan harga yang lebih rendah pesaingnya untuk usaha rantai apotek besar organisasi rumah

sakit. Jika tidak akan ditelan oleh salah satu pesaingnya yang lebih besar.

Pada tahun 1994 di pusat arsitektur teknologi informasi perusahaan terjadi penuaan

komputer mainframe Unisys dan sistem aplikasi umum tidak lagi fleksibel untuk perangkat keras

lama tersebut. sistem persediaan yang dimilikinya mampu melacak persediaan sehari-hari, tetapi

tidak bisa melacak persediaan menit demi menit saat pengiriman diterima atau dikirim.

Pergudangannya, seperti kebanyakan dalam industri apapun, belum dimodernisasi melalui instalasi

kemasan baru dan teknologi pengiriman.

Pada tahun 1994 manajemen memutuskan harus mengambil tindakan kuat untuk menjaga

independensi FoxMeyer dan membantu perusahaan bersaing dengan perusahaan besar. Strategi

yang mereka putuskan adalah menggunakan teknologi untuk "melompati kompetisi" menurut

Kenneth Woltz, seorang konsultan Chicago bagi FoxMeyer. Perusahaan ini mengumumkan proyek

sebesar $ 56 juta untuk mengembangkan dan memasang Sistem Informasi Delta. Sistem komputer

baru akan digunakan untuk mengelola operasi kritis yang terfokus utamanya pada pengendalian

persediaan. Rencana tersebut termasuk membangun gudang baru di Washington Court House, Ohio,

dengan robot terkomputerisasi yang dipakai untuk memenuhi pesanan pelanggan FoxMeyer di

bagian Midwestern. Tujuan khusus dari proyek inventarisasi ini mencakup percepatan perputaran

persediaan melalui biaya persediaan yang lebih baik, dan memberikan cara untuk lebih baik

melayani pelanggan dengan memberikan informasi FoxMeyer dengan lebih rinci tentang pola

masing-masing pemesanan pelanggan. Tujuan kunci lain adalah pemotongan biaya. Manajemen

memproyeksikan bahwa sistem baru, setelah sepenuhnya dilaksanakan, akan menghasilkan

penghematan tahunan sebesar $ 40 juta. Ini menunjukkan bahwa komputerisasi merupakan sebagai

puncak peningkatan efisiensi mereka," papar Christina Valauri yang bekerja di perusahaan tersebut

sebagai seorang analis untuk PaineWebber Inc. "Kami mempertaruhkan perusahaan kami ini,

"tandas Chief Information Officer Robert R. Brown untuk ComputeWorld.

Untuk membangun gudang baru 340.000 meter persegi, FoxMeyer menghabiskan sekitar $

18 juta. Perusahaan ini menyewa Anderson Consulting, perusahaan konsultasi sistem informasi

terkemuka internasional, baik untuk menasehati mereka tentang proyek dan untuk memasok tenaga

terampil yang bekerja untuk proyek tersebut. Walaupun perusahaan belum merilis informasi

tentang berapa banyak mereka membayar Anderson, sumber proyek mengklaim bahwa itu

berjumlah puluhan jutaan dolar. Proyek ini membeli R / 3, perangkat lunak sistem manajemen

persediaan dari SAP SAG, sebuah perusahaan perangkat lunak raksasa Jerman. Dalam beberapa

tahun terakhir perangkat lunak SAP telah menjadi begitu sangat dipuji, dan para profesional sistem

informasi bersaing untuk mendapatkan pengalaman SAP sehingga mereka dapat menjadi lebih

dipekerjakan dan mendapatkan kesempatan untuk permintaan upah tinggi. Walaupun SAP telah

dirancang untuk berjalan pada hardware Digital Equipment Corporation, namun FoxMeyer membeli

sistem client/server Hewlett-Packard Co dengan biaya $ 4,8 juta.

Perangkat lunak ini dirancang untuk berjalan pada perangkat keras klien / server dan

memiliki reputasi untuk bekerja dengan baik, memungkinkan pengguna untuk menggantikan

mainframe lama mereka. Pilihan perangkat keras terbukti tidak menjadi masalah serius karena

perangkat lunak pada akhirnya berjalan dengan baik pada peralatan Hewlett Packard. Namun,

perusahaan ini memiliki masalah serius lain karena " sistem tersebut sangat sulit untuk diterapkan,"

klaim Kenneth Woltz. Perangkat lunak Client / server agak rumit dan masih relatif baru pada saat itu.

Beberapa kesulitan telah muncul. Sumber nyata dari masalah software adalah bahwa tidak ada

grosir besar pernah menggunakannya pada waktu sebelumnya. Bahkan, SAP belum pernah

digunakan untuk transaksi yang banyak, dan klaim FoxMeyer bahwa kemudian pengalaman mereka

menunjukkan bahwa SAP hanya bisa menangani beberapa item ribu per hari. Selain itu, menurut

Woltz, "SAP awalnya dirancang bisnis manufaktur dan tidak memiliki banyak fitur untuk bisnis grosir

dan distribusi. Seorang juru bicara SAP mengklaim FoxMeyer "FoxMeyer harus memiliki orang untuk

menyempurnakan beberapa antarmuka antara SAP dan sistem yang telah ada. Hal itulah yang

menyebabkan beberapa penundaan". Menurut Douglas Schwinn, CIO FoxMeyer, bahwa selama

proses pengembangan mereka " melakukan beberapa simulasi, tapi tidak dengan tingkat data yang

kita miliki di lingkungan operasi."

Beberapa laporan menunjukkan bahwa sekali perusahaan telah berkomitmen untuk SAP,

manajemen tidak ingin lagi mendengar tentang masalah yang terjadi. Sejumlah orang mengaku

mereka didorong untuk meminimalkan masalah. Seorang manajer berpendapat, "Itu tidak tepat

untuk mengkritik SAP." Seorang konsultan untuk proyek tersebut mengatakan, "Setiap kali kita

menunjukkan sesuatu yang tidak bekerja, mereka akan berkata 'Apakah ini deal-breaker?'"-

implikasinya bahwa jika tidak, proyek ini akan terus berlanjut. Konsultan yang sama juga

menambahkan bahwa "tidak ada satu [masalah] merupakan deal-breaker. Tetapi jika anda menaruh

cukup blok bara di perahu dayung, maka perahu tersebut akan tenggelam. "

Masalah perangkat lunak diperbesar oleh perubahan kondisi bisnis. Pada bulan Mei 1993,

Phar-Mor Inc, sebuah rantai farmasi Midwestern, mengajukan perlindungan kebangkrutan. Sekitar

15 persen dari total bisnis FoxMeyer datang dari rantai tersebut. Manajemen FoxMeyer bekerja

pada asumsi bahwa ia harus tumbuh untuk bertahan hidup, dan eksekutif FoxMeyer menyadari

bahwa bisnis Phar-Mor tersebut hilang secara permanen, mereka menjadi khawatir bahwa mereka

tidak akan dapat tumbuh cukup untuk tetap independen. Mereka meluncurkan pencarian mendesak

untuk pelanggan baru dan akhirnya menemukan Konsorsium University Health System, sebuah

aliansi nasional rumah sakit pendidikan utama. Pada Juli 1994 perusahaan menandatangani kontrak

lima tahun dengan pengiriman dijadwalkan yang dimulai pada awal tahun 1995. Manajemen

mengumumkan bahwa kontrak akan menghasilkan $ 4 sampai 5 milyar pada pendapatan selama

lima tahun kontrak. Namun, untuk memenuhi batas waktu yang ditetapkan untuk menangani

pesanan University Health System yang agresif, implementasi software SAP harus bergerak maju tiga

bulan, meskipun masalah serius sedang terjadi. Seorang programmer berkomentar, "Saya tidak akan

pernah berencana untuk memajukan implementasi, hingga 90 hari." Kemudian FoxMeyer

mengatakan bahwa mereka mulai memenuhi pesanan University HealthSystem tepat waktu, tetapi

University HealthSystem menolak berkomentar.

Setelah sistem baru diterapkan, masalah data yang serius mulai terungkap. Salah satu

hasilnya adalah bahwa FoxMeyer tidak dapat menggunakannya untuk memonitor pola pembelian

pelanggan, salah satu tujuan utama dari proyek tersebut. Programmer menunjukkan bahwa alasan

masalah tidak ditemukan sampai mereka telah terbiasa dengan sistem ini adalah bahwa ternyata tim

proyek tidak punya waktu untuk menguji semua itu. Misalnya, mereka melewatkan bagian mana pun

dari pengujian perangkat lunak SAP yang tidak mereka sesuaikan. Menariknya, meskipun sistem

punya masalah data menit-demi-menit, hal itu menghasilkan tagihan yang secara akurat

mencerminkan pesanan pelanggan. Hasil ironis dari penagihan yang akurat adalah bahwa hal itu

memberikan kontribusi terhadap masalah lebih besar karena, seperti yang akan kita lihat, tidak

mencerminkan tagihan yang sebenarnya dikirim.

Masalah pengiriman utama muncul dari gudang Ohio yang baru. Sistem otomatis ini

dirancang untuk mengambil 80 persen dari semua item secara otomatis, dibandingkan dengan rata-

rata industri 33 persen. Tingginya tingkat otomatisasi adalah menjadi kunci bagi layanan FoxMeyer

yang terbaiki dan biaya lebih rendah. Sistem ini mengandalkan bar coding, pembaca bar-code, dan

konveyor otomatis untuk memilih produk dan secara otomatis meletakkannya ke dermaga dan truk

yang tepat. Sistem ini, ketika pertama kali diinstal, penuh bug dan terus mematikan elemen kritis

seperti carousels dan konveyor. Juga, scanner sering gagal untuk membaca barcode yang terpasang

di kotak. Pergudangan dibuka pada Agustus 1995, tiga bulan terlambat dan dengan banyak bug yang

sama masih tidak berhasil terpecahkan. Perusahaan ini dipaksa untuk membuka gudang baru

meskipun sistem masih banyak mengalami kekurangan, karena keberangkatan dari banyak anggota

staf gudang berpengalaman ke gudang tua. Mereka telah mampu membaca tulisan tangan yang jelas

di dinding - sebagian besar dari mereka akan digantikan oleh sistem otomatis yang baru. Ketika

mereka pergi, perusahaan diganti dengan temps sampai gudang baru dibuka, tapi temps tidak

mampu menangani pekerjaan dan pelayanan sangat memburuk, memaksa pembukaan gudang baru

sebelum masalah dikoreksi.

Saat sistem di gudang baru berulang kali gagal selama jam kerja tersibuk, operator harus

menghentikannya dan kemudian mengawalinya kembali. Kotak-kotak kemasan tidak mencapai

posisi pemuatan mereka tepat waktu. Banyak pekerjaan yang harus dilakukan secara manual dengan

data yang dimasukkan ke dalam komputer secara manual kemudian, menyebabkan banyak

kesalahan dalam sistem. Masalah yang paling penting adalah bahwa banyak pesanan yang

dikirimkan dengan barang yang hilang tetapi dengan faktur yang lengkap. Dalam banyak kasus,

barang yang hilang terlambat tiba di dermaga karena sistem truk tindak lanjut. Pelanggan melihat

kualitas layanan menurun karena mereka tidak menerima faktur barang-barang tersebut ketika

pengiriman asli tiba. Para pelanggan yang menghubungi layanan pelanggan FoxMeyer's yang barang

pesanannya hilang dikirim pada hari berikutnya. Kemudian, barang yang hilang akan tiba pada truk

berikutnya. Hasilnya adalah bahwa ketika pengiriman barang hilang yang dipesan oleh customer

service tiba keesokan harinya, banyak pelanggan menerima barang-barang dengan jumlah ganda.

Namun, karena sistem persediaan SAP menghasilkan tagihan yang akurat hanya berdasarkan

pesanan, pelanggan tidak ditagih untuk menyerahkan kembali barang-barang dengan jumlah ganda.

Hasil yang tidak terduga adalah bahwa banyak pelanggan tidak repot-repot melaporkan overages.

Schwinn men-klaim, "Dahsyatnya duplikasi pemesan tidaklah jelas sampai kita melakukan

inventarisasi," tetapi masalah tersebut menyebabkan kehilangan besar untuk FoxMeyer. Perusahaan

ini dipaksa untuk mengumumkan $ 34 juta biaya untuk menutup kerugian tidak tertagihnya pesanan

pelanggan. Faktanya adalah perusahaan tidak tahu siapa yang menggandakan pesanan yang dikirim

atau isi dari pesanan-pesanan tersebut.

Aspek lain dari bencana pengembangan adalah keberanian manajemen FoxMeyer untuk

membuat tawaran yang sangat rendah untuk kontrak untuk memperbesar pelanggan berdasarkan

pada asumsi bahwa sistem otomatis akan mengurangi biaya secara dramatis. Mereka bahkan

memenangkan kontrak Konsorsium University HealthSystem dengan tawaran rendah yang agresif

meski fakta bahwa sebagian besar rumah sakit berada di Pantai Barat dimana FoxMeyer tidak

memiliki gudang di tempat tersebut. Ketika membuat tawaran, FoxMeyer tahu itu akan

mengakibatkan mereka harus membangun enam gudang baru di kawasan ini. Sekali lagi, mereka

mengharapkan efisiensi dari sistem otomatis baru untuk membuat kontrak tersebut

menguntungkan.

Saham FoxMeyer's sangat menderita karena masalah otomatisasi. Saham, yang mencapai

angka tertinggi $ 26 per saham pada tahun 1994 ketika proyek Delta diumumkan, turun menjadi

sekitar $ 3 per saham pada bulan Desember tahun itu. Perusahaan ini akhirnya mengajukan

perlindungan pengadilan di bawah Bab 11 UU Kepailitan Federal. Wade Hyde, seorang juru bicara

FoxMeyer, mengklaim bahwa "pada dasarnya, masalah integrasi komputer yang kita punya adalah

faktor yang signifikan mengarah kebangkrutan." Kemudian, McKesson Corp mampu membeli

FoxMeyer Obat Co untuk hanya $ 80 juta secara tunai. FoxMeyer memang mempertaruhkan

perusahaannya pada sistem baru, dan akhirnya perusahaan tersebut merugi.

Menariknya, mereka yang masih terlibat mengklaim bahwa sistem otomasi akhirnya

bekerja seperti yang diharapkan setelah masalah diselesaikan. Mr Schwinn meng-klaim bahwa

proyek otomatisasi secara menyeluruh menghemat banyak uang perusahaan, meskipun tidak

mencapai tujuan $ 40 juta karena komplikasi yang terlibat dengan kontrak University HealthSystem.

Studi Kasus Bagian III : MODERNISASI SISTEM ADMINISTRASI PADA JAMINAN SOSIAL: 1982 - 1997

The Social Security Administration (SSA) yang terdiri dari sekitar 63.000 karyawan yang

berlokasi di 1300 kantor lapangan, 10 kantor regional, 37 pusat Teleservice, 7 pusat pengolahan, 4

operasi pusat data, dan markas Baltimore. SSA mengelola program asuransi besar sosial dari

Amerika Serikat dan beberapa program terkait lainnya, yang meliputi:

• Pensiun dan Asuransi Korban (RSI)

• Cacat Asuransi (DI)

• Keamanan Penghasilan Tambahan (SSI)

Dalam rangka untuk melaksanakan program ini, SSA mempertahankan 260 juta nama

dalam file nomor rekening nya (file pencacahan), 240 juta pendapatan catatan, dan 50 juta nama

pada file penerima yang master. Selain menjaga berkas ini saat ini, SSA setiap masalah 10 juta baru

Sosial kartu Jaminan membayar keluar $ 170 milyar, posting 380 juta item upah yang dilaporkan oleh

majikan, menerima 7,5 juta klaim baru, recomputes (karena perubahan status penerima) 19 juta

rekening dan menangani 120 juta tagihan dan pertanyaan dari perusahaan asuransi kesehatan

swasta, pengusaha dan perantara. Hampir setiap warga Amerika yang hidup memiliki hubungan

dengan SSA.

Pada awal 1980-an, dana jangka panjang untuk pembayaran jaminan sosial di Amerika

Serikat dalam bahaya serius, dan sistem komputerisasi SSA's administrasi hampir runtuh. Ini adalah

sebuah negara yang tidak biasa untuk urusan SSA. Sebagai institusi unggulan dari New Deal, SSA

telah mengembangkan dukungan bipartisan yang luas, dan tidak pernah ada pertanyaan serius

tentang jangka panjang kelangsungan keuangan sampai akhir 1970-an. Selain itu, sejak didirikan

pada tahun 1935, SSA telah menjadi salah satu inovator terkemuka dan pelaksana teknologi

informasi maju di Amerika Serikat. Dengan hubungan jangka panjang khusus dengan IBM bentuk

pertengahan 1930-an sampai akhir 1960-an, SSA adalah sebuah situs tes untuk banyak hardware

terkemuka komersial dan inovasi perangkat lunak periode ini.

Pada tahun 1982, SSA mengumumkan Rencana Modernisasi Sistem (SMP), upaya $

500.000.000 lima tahun untuk sepenuhnya membangun kembali informasi yang sistem dan proses

administrasi. Sejak itu, SMP telah diperluas menjadi $ 1 milyar dan 10 tahun. SMP adalah salah satu

sistem informasi terbesar sipil membangun kembali usaha dalam sejarah. Sepuluh tahun kemudian,

SSA memulai suatu putaran ambisius lain modernisasi teknologi seperti yang mencoba untuk

menciptakan sebuah arsitektur informasi untuk abad kedua puluh satu.

SSA menggambarkan masalah banyak pusat manajemen, teknologi informasi dan organisasi yang

dihadapi oleh organisasi-organisasi swasta dan publik dalam masa perubahan teknis dan sosial yang

cepat. Meskipun SSA beroperasi di lingkungan pemerintah federal yang unik, banyak organisasi

swasta besar telah menunjukkan masalah yang sama dalam periode ini. Masalah dan solusi

diilustrasikan dalam kasus ini adalah generik.

Kasus ini disusun dalam tiga bagian. Bagian 1 menggambarkan seluruh situasi SSA pada

periode sebelum SMP, sekitar 1972-1982. Bagian 2 menjelaskan pengalaman SMP. Bagian 3

mempertimbangkan prospek jangka panjang dari SSA.

Bagian 1: Organisasi, manajemen, dan sistem, 1972-1982.

Lingkungan sistem secara keseluruhan di SSA tahun 1982 terbaik dapat digambarkan

sebagai campur aduk program software yang dikembangkan selama periode 20 tahun dalam empat

lingkungan yang mesin yang berbeda. Dalam sejarah lembaga ini, tidak ada yang pernah melakukan

studi sistem informasi persyaratan untuk memahami persyaratan keseluruhan agen atau

persyaratan spesifik dari subunit nya. Tidak ada perencanaan sistem informasi fungsi selama lebih

dari 20 tahun. Sebaliknya, sebagai organisasi swasta banyak, sistem hanyut bersama dari tahun ke

tahun, dengan hanya perubahan inkremental.

Perangkat Lunak

Perangkat lunak SSA dihasilkan dari dekade teknik pemrograman. Sistem pencacahan, yang

mendukung penerbitan os nomor Jaminan Sosial, dirancang pada akhir 1950-an dan tidak pernah

berubah. Sistem produktif dirancang pada tahun 1975, sistem memproses klaim tidak berubah dari

awal 1960-an, dan sistem lain juga diwarisi dari akhir 1960-an dan 1970-an. Perangkat lunak ini

merupakan produk dari kain perca yang tidak direncanakan, tanpa memperhatikan yang diberikan

kepada penurunan dari waktu ke waktu.

Dari tahun 1950 hingga 1980-an, ada empat transisi peralatan utama. Namun, perangkat

lunak itu tidak ditingkatkan atau dirancang ulang pada setiap transisi ini. Semua file SSA dan program

tetap dipertahankan pada lebih dari 500.000 gulungan magnetic tape yang rentan terhadap

penuaan, keretakan dan kerusakan. Karena tape adalah media penyimpanan, semua pemrosesan

data berurutan batch.

Singkatnya, ada 76 perangkat lunak yang berbeda membuat sistem operasi dasar ujung

SSA's komputer. Sistem perangkat lunak itu sendiri kumpulan program yang melakukan fungsi bisnis

utama dari SSA. Ada program komputer lebih dari 1300 yang meliputi lebih dari 12 juta baris COBOL

dan kode lainnya.

Sebagian besar dari 12 juta baris kode yang tidak berdokumen. Mereka bekerja tetapi

hanya sedikit orang dalam organisasi tahu bagaimana atau mengapa, yang membuat pemeliharaan

sangat kompleks. Pada tahun 1960 dan 1970-an, Kongres dan presiden melakukan perubahan terus-

menerus dalam formula manfaat, masing-masing yang membutuhkan perawatan yang luas dan

perubahan dalam perangkat lunak yang mendasari. Sebuah perubahan tarif biaya-of-hidup,

misalnya, diperlukan menyortir melalui beberapa program terjalin besar, yang mengambil bulan

bekerja.

Karena pekerjaan padat karya diperlukan untuk mengubah perangkat lunak

didokumentasikan dan krisis kegiatan yang meningkat, staf pengembangan perangkat lunak yang

umumnya bergeser untuk mengelola operasi crisi. Hasilnya adalah pengembangan kecil program

baru.

Ini tidak membantu hal-hal yang beberapa orang di Kongres, Kantor Presiden, Kantor

Manajemen dan Anggaran, atau pihak yang bertanggung jawab lainnya memahami dampak buruk

dari perubahan program pada kemampuan SSA sistem. Sayangnya, SSA tidak memberitahu Kongres

keterbatasan sendiri.

Apa yang tidak biasa tentang SSA adalah bahwa pada akhir tahun 1970 itu tidak mulai

melakukan transisi ke teknologi penyimpanan baru, file manajemen dan teknologi database atau

lebih teknik perangkat lunak modern. Dalam hal ini, SSA adalah sekitar lima tahun di belakang

industri swasta dalam melakukan transisi teknologi penting.

Perangkat keras

Pada tahun 1982, SSA beroperasi ketinggalan jaman, tidak dapat diandalkan, dan

perangkat keras yang tidak memadai, mengingat misinya. Banyak komputer belum diproduksi atau

dipasarkan selama 10 tahun atau lebih. Sebelas IBM 360/65 sistem tidak lagi diproduksi atau

didukung. Meskipun peralatan yang lebih modern mungkin diperlukan $ 1.000.000 per tahun untuk

biaya pemeliharaan dan operasional, SSA menghabiskan lebih dari $ 4 juta untuk menjaga mesin

kuno dalam pelayanan.

Hardware kuno dipaksa SSA bergantung pada layanan pemeliharaan pihak ketiga. Karena

kerusakan sering, lebih dari 25 persen dari pekerjaan produksi berakhir sebelum selesai (pekerjaan

abended), dan 30 persen dari kekuatan pemrosesan komputer yang tersedia adalah menganggur.

Sebagai akibat dari kekurangan perangkat keras, sejumlah dampak program khusus menjadi jelas

pada tahun 1982:

operasi penegakan Laba, yang membantu mendeteksi lebih dari pembayaran, lebih dari tiga

tahun di belakang jadwal.

Perhitungan jumlah manfaat untuk memberikan kredit untuk penghasilan tambahan setelah

pensiun tiga tahun di belakang jadwal.

SSI klaim dan redeterminations posteligibility dapat diproses hanya tiga kali seminggu lebih dari

lima kali seminggu. Ini berarti penundaan beberapa hari atau minggu untuk penerima SSI.

Untuk biaya proses atau peningkatan hidup pada tahun 1982 sebesar 42 juta individu, SSA harus

menangguhkan semua pengolahan data lainnya selama satu minggu.

Pada tahun 1982, ada backlog tiga-bulan data yang diperlukan untuk memberitahu majikan

tentang salah melaporkan pendapatan karyawan. Hal ini menciptakan sebuah file ketegangan

dengan lebih dari 2 juta entri un-mencatat pendapatan dan pekerjaan manual yang diperlukan

tambahan untuk menangani korespondensi majikan.

SSA memperkirakan bahwa kapasitas komputasi kotor itu kekurangan lebih dari 2000 jam

CPU per mont, namun kapasitasnya jam CPU hanya 3000 per bulan.

Telekomunikasi

SSA sangat tergantung pada telekomunikasi untuk melakukan misinya. 1300 Its kantor

lapangan perlu akses yang tepat terhadap data yang disimpan di fasilitas komputer pusat di

Baltimore. Pada tahun 1982, bagaimanapun, telekomunikasi SSA adalah hasil dari suatu sistem

berkembang dating kembali ke 1966. Sistem telekomunikasi utama disebut Administrasi Keamanan

Sosial Data Akuisisi dan Sistem Tanggap (SSADARS), yang dirancang untuk menangani 100.000

transaksi per hari. Satu teleprocessing tahun tumbuh sebesar 100 persen. Dengan 1.982 jaringan

SSADARS sering menghancurkan dan usang dan sangat tidak efisien.

Salah satu akibat dari sistem komunikasi jenuh adalah eksekutif senior SSA lokal yang

bekerja di petugas lapangan dipaksa untuk datang pada akhir pekan untuk memasukkan data ke

sistem SSADARS, yang dimuat selama lebih dari seminggu. Pada tahun 1982, ada sedikit sisa

kapasitas CPU telekomunikasi di masa puncak off untuk menangani pertumbuhan normal beban

kerja saat ini. Seluruh aliran komunikasi sering hilang. Pada saat puncak, ketika kebanyakan orang

ingin menggunakan sistem, itu hanya tersedia. Hasilnya adalah telekomunikasi backlogs berkisar

10,000-100,000 pesan pada suatu waktu.

Database

Penggunaan istilah database hanya dapat digunakan pada makna yang hilang untuk merujuk

pada 500.000 gulungan megnetic tape SSA yang mana menyimpan informasi pada klien di dalam

bidang program besar. Setiap bulan SSA melakukan 30.000 pekerjaan produksi, membutuhkan lebih

dari 150.000 tape untuk diload ke dalam dan mematikan mesin. Tape tersebut tidak bersatu dan

salah di dalam tape, selama bersama penguraian fisiknya, menyebabkan error rate yang sangat

tinggi dan memaksakan nilai kembalian. Lebih dari 1/3 staf operasi (200 orang) dibutuhkan untuk

menangani tape tersebut.

Seperti pada kebanyakan organisasi sektor pribadi, data diorganisasi di SSA oleh program

dan banyak elemen data yang diulang dari satu program ke yang lainnya. SSA memperkirakan bahwa

ada lebih dari 1300 program terpisah, masing-masing memiliki set data sendiri. Karena tidak adanya

fungsi data, maka menjadi sulit untuk menggambarkan jumlah total elemen data, atau level

redundansi di dalam agen sebagai kesatuan atau di dalam bidang program.

Sistem Informasi Manajemen

Pada 1982, SSA memiliki kemampuan di bidang MIS (Management Information System) yang

sangat tidak cukup. Karena data disimpan pada magnetic tape dan tidak tersedia secara umum bagi

manajer pengguna akhir di semua bagian organisasi, semua permintaan laporan harus dituangkan

lewat bidang operasi sistem informasi.

Akan tetapi terdapat krisis dalam pengoperasian dan ini berarti penundaan beberapa tahun

dalam bidang produksi laporan penting untuk pengambilan keputusan manajemen. Sepanjang data

disimpan di dalam format yang membutuhkan komputer profesional dan ahli sistem informasi untuk

memperoleh akses padanya, manajemen umum selalu memiliki kesepakatan dengan departemen

sistem. Kelompok ini memiliki kendali yang kuat terhadap oragnisasi. Atitud mereka merupakan satu

komentator tercatat, dan perhitungan dalam pernyataan “Jangan ganggu kami atau cek tidak akan

keluar”.

Bagaimana Hal Ini Bisa Terjadi?

Ada dua penjelasan untuk jatuhnya SSA dari posisi pimpinan sistem pada tahun 1980-an.

Pertama, adanya faktor institusi internal yang melibatkan manajemen senior dan madya. Kedua,

terkadang perubahan lingkungan yang cepat dan tidak ramah pada tahun 1970-an turut

mempersulit SSA.

Pada tahun 1970-an, kongres telah membuat lebih dari 15 perubahan besar dalam program

RSI. Perubahan ini menaikkan beban sistem SSA pada intinya bahwa personel program bekerja pada

akhir minggu untuk membuat perubahan program.

Pada tahun 1972, kongres meloloskan SSI (Supplemental Security Income) yang

mengkonversi biaya yang sudah ditentukan dan mengurus program pemeliharaan pendapatan ke

dalam program federal. SSA tiba-tiba menghadapi arena kemakmuran, yang mana dulunya

menghapuskan dari agen asuransi sosial. Staf lokal yang tidak dipersiapkan tiba-tiba menghadapi

ribuan pelamar yang marah. Kerusuhan terjadi di beberapa kota. Program lainnya seperti kesehatan

dan perubahan dalam ketidakmampuan asuransi, sebaik biaya hidup (COLA), semua membebani

sistem SSA dan kapasitas personal. COLA tahun 1978 membutuhkan pergantian pada lebih dari 800

program komputer SSA.

Jumlah klien yang dilayani oleh SSA menjadi dua kali lipat pada 1970-an. Akan tetapi karena

pertumbuhan krisis ekonomi bersama dengan pertumbuhan yang rendah dan inflasi yang tinggi

(stagflation), kongres tidak bersedia memperluas usaha pekerjaan SSA untuk mendapatkan

permintaan dari program baru. Terdapat pertumbuhan publik dan resistensi politik untuk

memperluas pegawai pemerintahan federal ketika program baru datang dan harapan akan

pelayanan program meningkat.

Manajemen SSA pada periode ini membesar-besarkan kapasitas administrasinya kepada

kongres dan gagal mengkomunikasikan pertumbuhan krisis sistem. SSA menginjinkan pemecatan

orang oleh kongres dan White House. Beban kerja pegawaipun menigkat, sementara moral dan

kepuasan kerja menurun. Training dihapuskan, terutama pada bidang sistem, semua sumber daya

dialihkan pada krisis operasi.

Mendekati akhir tahun 1970-an, lingkungan politik berganti baik. Pertumbuhan pergerakan

konservatif antara Republik dan Demokrat mampu menghilangkan semua program federal yang

mana mengarah pada kenaikan tekanan pada SSA untuk menghilangkan level pegawai. Dalam

perdebatan yang panjang tentang pendanaan yang dimulai pada tahun 1980-an membicarakan

tentang “privasi” keamanan sosial dan menghapuskan agen sama sekali.

Memperburuk keadaan SSA yaitu Brooks Act pada tahun 1965, yang mana merupakan

perintah untuk usaha persaingan dalam memperoleh perlengkapan dan pelayanan komputer.

Setelah 1965, SSA memiliki relasi yang menguntungkan dan berkelanjutan dengan IBM. Secara

virtual, semua peralatan SSA dimanufaktur oleh IBM dan dijual pada basis non kompetitif. IBM

menyediakan perencanaan, dukungan teknis, dan pelayanan konsultasi untuk SSA yang merupakan

bagian dari hubungan ini.

Pada tahun 1970-an, hubungan yang dekat ini berakhir. IBM merubah dukungan dan usaha

penjualannya jauh dari arena federal karena Brook Act. SSA menghadapi lingkungan persaingan

baru, berusaha melakukan semua rencana, pengembangan dan usahanya sendiri. Beban kerja

meluas dengan sangat cepat, agen membutuhkan perencanaan yang baik, perencanaa transisi

manajemen untuk peralatan komputasi dan software. Transisi ini tidak pernah terjadi.

Lingkungan yang menantang mungkin diatasi oleh kelompok manajemen berfokus dan

berdedikasi. Kadang kelemahan yang sangat kritis dari semua operasi SSA pada tahun 1970-an

adalah ketidakmampuannya untuk mengontrol manajemen di atas fungsi sistem informasi dan

sumber daya manajemen yang mana mendasari organisasi tersebut.

Pergantian manajemen senior merupakan masalah kritis. Untuk 38 tahun pertama, SSA

memiliki 6 komisioner dengan masa jabatan rata-rata 6.5 tahun. Dua orang memimpin agen selama

27 tahun dari 38 tahun. Akan tetapi dari tahun 1971 sampai 1981, SSA memiliki 7 komisioner dengan

rata-rata masa jabatan 1.1 tahun. Tidak satupun dari semua komisioner memiliki pengalaman di SSA.

Staf senior agen juga secara berulang diguncang pada periode ini. Dibandingkan dengan manajer

senior sebelumnya, manajer pada tahun ini gagal untuk menyadari kepentingan kritis dari sistem

informasi untuk operasi SSA. Perencanaan jangka panjang dari agen atau sistem menjadi tidak

mungkin. Autoritas berjalan dengan lambat akan tetapi tak dapat dihindarkan beralih kepada

kelompok level operasi, yang merupakan satu-satunya pihak yang mengetahui apa yang terjadi.

Dengan manajemen senior yang baru yang berasal dari 4 organisasi besar agen. Program SSA

besar dipatahkan ke dalam bagian fungsional dan didistribusikan ulang menjadi divisi fungsional

baru. Hubungan koheren programpun lenyap. Ukuran kinerja dan kontrol manajemen menghilang

sebagai manajer dan pegawai yang berjuang untuk beradaptasi dengan fungsi barunya.

Usaha dalam Perubahan

SSA membuat beberapa usaha pada periode ini untuk memulihkan kontrol dan arah pada

bidang sistem yang mana semua operasinya bergantung secara kritis. Di tahun 1975, SSA membuat

OAS (Office of Advance System) di dalam kantor komisioner. SSA berharap kemajuan ini, kelompok

rencana level atas dengan akses langsung ke manajemen senior akan mengembangkan sebuah

strategi untuk perubahan. Sayangnya usaha ini gagal untuk membentuk kembali panduan dan proses

batch SSA dan ditentang oleh manajemen operasi sistem dan gabungan. Tidak ada dukungan dari

White House untuk itu dan tidak ada saran dari kongres atau White House bahwa dana yang

diperlukan akan tersedia. Di tahun 1979 OAS dihapuskan oleh tim manajemen baru.

Usaha kedua untuk pemulihan dimulai pada tahun 1979. Saat itu ide berasal dari

manajemen senior baru. Disebut partitioning, merupakan usaha pemulihan baru untuk memecahkan

operasi internal SSA ke dalam baris program besar, sama dengan baris produk. Sehingga setiap

program harus bisa mengembangkan sistemnya sendiri. Rencana ini dengan cepat ditolak oleh

White House, kongres dan profesional lainnya.

Usaha pemulihan ketiga dimulai pada 1979 juga. Di sini SSA mengganti jaringan

telekomunikasi SSADARS dengan terminal baru dan berkecapatan tinggi di kantor distrik dan

komputer telekomunikasi baru di kantor pusat Baltimore. Setelah proses usaha yang kompetitif, SSA

kontrak dengan Paradyne Corporation untuk 2000 terminal. Namun sayangnya, 16 sistem pertama

gagal untuk semua tes operasi pada pengiriman pada tahun 1981. Investigasi menghasilkan

pemungutan biaya tipuan(sistem penjualan kepada SSA yang tidak ada), tipuan keamanan,

penyuapan, penawaran kepentingan pribadi, pelanggaran janji, dan ketidakcukupan definisi

kebutuhan sistem SSA. Pada 1983 SSA mengambil pengiriman dari semua terminal, dan mereka

tidak menunjukkan untuk harapan kehidupan mereka dalam 8 tahun. Akan tetapi skandal lebih jauh

menghilangkan kredibilitas SSA dalam kongres dan White House.

Manajemen senior teralihkan, kehilangan konsentrasi, dan usaha yang gagal pada pemulihan

mengambil beberapa korban dalam bidang sistem. Perencanaan sistem informasi baik itu dilakukan

maupun tidak dilakukan seperti level operasional bahwa perubahan besar di dalam operasi dapat

diselesaikan.

Section II : Perencanaan Organisasi Sistem

Krisis di dalam SSA dapat meningkat nyata pada kongres, kantor akuntansi umum, dan

kantor Presiden, tekanan ditempatkan pada SSA untuk mengembangkan strategi baru. Pada tahun

1981 seorang komisioner baru, John Svahn, pendiri akhir asuransi eksekutif dengan pengalaman

sistem, memulai pekerjaan pada perencanaan strategis untuk mencoba memindahkan pemrosesan

data SSA dari kegagalan menjadi sistem modern. Hasilnya perencanaan 5 tahun yang disebut System

Modernization Plan (SMP). SMP diubah untuk membawa periode panjang, perubahan terintegrasi

yang tinggi dalam software, hardware, telekomunikasi, dan sistem manajemen. Pada $500 juta,

biaya asli diperkirakan pada 1982, SMP merupakan satu dari proyek sistem manajemen dalam

sejarah. Tujuan SMP yaitu :

Mengembalikan keuntungan kepada sistem SSA dan mengembalikan agen kepada status

posisinya

Menghindarkan perpecahan pelayanan.

Meningkatkan pelayanan secara mendadak dengan menjual hardware modern

Meningkatkan efektifitas dan produktifitas staf

Mengembalikan kepercayaan umum dengan meningkatkan tanggung jawab, dapat diperiksa

dan deteksi penipuan.

Strategi SMP

Sebagai usaha berani untuk mengamankan seluruh perubahan pada SSA, SMP mengadopsi

sebuah strategi konservatif. Strategi ini mengaharuskan SSA melakukan hal-hal berikut :

Menerima modernisasi melalui peningkatan, perubahan evolusioner, memberikan resiko

kegagalan yang tak dapat diterima.

Membangun sistem yang ada, memilih jangka pendek, pendekatan yang layak yang

meminimalkan resiko

Memisahkan program modernisasi dari operasi dan pemeliharaan program.

Implementasi SMP

Rencana awal meramalkan upaya lima tahun dibagi menjadi tiga tahap kelangsungan

hidup, transisi, dan negara seni. Pada tahap survival (18 bulan), SSA akan fokus pada akuisisi

perangkat keras baru untuk memecahkan masalah kekurangan kapasitas segera. Pada tahap

transisi (18 bulan), SSA akan mulai membangun kembali perangkat lunak, file data, dan

sistem telekomunikasi. Dalam keadaan akhir tahap seni, SSA akan merampungkan dan

mengintegrasikan proyek untuk mencapai tingkat kontemporer sistem. SMP melibatkan enam

program yang saling terkait.

1. Kapasitas Upgrade Program (CUP). Piala dikembangkan untuk mengkonfigurasi

ulang dan mengkonsolidasikan situs komputasi fisik di sekitar kantor pusat di Baltimore

untuk mendapatkan kapasitas yang lebih tinggi dan komputer yang lebih modern untuk

menghilangkan berurutan terorganisir file pita magnetik dan beralih ke perangkat akses

langsung dan untuk mengembangkan jaringan komputasi lokal untuk kecepatan tinggi

transfer data.

2. Sistem Operasi dan Program Manajemen (SOMP). SOMP dimaksudkan untuk

memberikan alat otomatis modern dan prosedur untuk mengelola anf mengendalikan operasi

komputer pusat utama SSA di Baltimore. Termasuk adalah alat penjadwalan otomatis

pekerjaan, stasiun pemantauan dan penyerahan pekerjaan sistem, prosedur kerja operasional,

pelatihan, dan kontrol fasilitas pusat terpadu untuk memastikan bahwa SSA akan membuat

kelancaran transaksi ke lingkungan data center modern.

3. Komunikasi Data Utility Program (DCUP). DCUP dirancang untuk ulang sistem

telekomunikasi utama SSA's (SSADARS). Apa SSA inginkan adalah sebuah condult

transparan untuk transmisi data antara dan antar unit pengolahan manufaktur yang berbeda

menggunakan jaringan tunggal terintegrasi. Lebih dari 40.000 terminal on-line yang akan

digunakan di 130 kantor lapangan.

4. Software engineering Program (SEP). SEP adalah desain untuk meng-upgrade

perangkat lunak keluar dan mempertahankan sebanyak itu mungkin sehingga kode yang sama

sekali baru tidak harus ditulis. Sebuah bagian penting dari September adalah analisis atas ke

bawah, fungsional (menggunakan metode perusahaan sistem perencanaan) dari proses

jaminan sosial - semua bisnis dan fungsi organisasi SSA. Semoga upaya ini perencanaan top-

down akan memberikan kerangka untuk mendesain ulang sistem SSA's total dengan

membangun kebutuhan untuk perbaikan dalam perangkat lunak yang ada. Sebuah aspek

kunci kedua dari upaya rekayasa perangkat lunak adalah penerapan teknologi rekayasa

perangkat lunak baru. Ini melibatkan mengembangkan dan menerapkan standar

pemrograman, mengembangkan kontrol kualitas, dan menggunakan alat-alat modern

komputer pengembangan perangkat lunak dibantu. Penekanan khusus ditempatkan pada

pengembangan dokumentasi program modern, standarisasi program, dan konversi ke bahasa

tingkat yang lebih tinggi bila memungkinkan.

5. Integrasi Database. Proyek integrasi database melibatkan empat tujuan. Sebagai

taktik bertahan hidup, SSA ingin mengurangi tenaga kerja saat ini intensif, operasi pita rawan

kesalahan magnetik dengan mengkonversi semua catatan t disk kecepatan tinggi, perangkat

penyimpanan akses langsung (DASD). Tujuan kedua adalah untuk menyelenggarakan fungsi

data administrasi untuk mengontrol definisi unsur data dan file. Tujuan ketiga adalah untuk

menghilangkan data errord dengan menetapkan kontrol data, memvalidasi file, dan

mengembangkan teknologi penyimpanan disk modern. Tujuan keempat adalah untuk

mengintegrasikan berbagai database membuat komunikasi di antara mereka transparan.

6. Manajemen Administrasi Program Studi Teknik Informatika (Amien). SSA

pada dasarnya tergantung pada kegiatan manual untuk melakukan sebagian besar

administrasi. Permintaan untuk pembelian tindakan personel permintaan, layanan telepon,

perintah perjalanan, bangunan modifikasi, pelatihan permintaan - semua urusan administrasi

diproses secara manual. Program Amie dirancang untuk mengintegrasikan MIS dengan

kegiatan lain modernisasi program untuk mengotomatisasi dan memodernisasi proses

administrasi padat karya dan untuk mengembangkan MIS manajemen untuk meningkatkan

perencanaan dan proses administrasi.

The End of SMP: Sukses dan Kegagalan

SMP telah menjadi semakin kontroversial: Kritik diklaim gagal ketika pemimpin

badan diklaim sukses. Dengan 1988 Dorcas Hardy, komisaris SSA baru, diam-diam berakhir

SMP dan mengumumkan rencana baru bernama "2000: Strategis polos." Apa memiliki

Dicapai SMP dalam lima tahun?

Untuk sebagian besar tahun-tahun sebelumnya SMP lingkungan itu mendukung dan

simpatik dengan program modernisasi. Pada tahun 1986, bagaimanapun, kritik mulai

mengembangkan atas meningkatnya biaya dan waktu seakan tak ada habisnya. Pada bagian

besar yang kritis menarik kekuatan dari kenyataan proyek SMP telah diperpanjang oleh SSA

untuk lima tahun tambahan (untuk 1992) dan memiliki dua kali lipat biaya diharapkan dapat

$ 1 miliar tidak ada terobosan software utama yang jelas kepada masyarakat atau Kongres

dan upaya untuk memodernisasi backend SSA atau database tampaknya kios.

Gedung Putih semakin ditekan SSA untuk membuat rencana untuk mengurangi staf

dengan seperempat, atau 20.000 posisi. Pada akhir 1988, staf SSA telah berkurang 17,000

pekerja dari 83,000 ke 66,000, kebanyakan oleh gesekan. Pengurangan ini dibuat untuk

mengantisipasi peningkatan tajam dalam produktivitas dibawa oleh upaya modernisasi SMP.

Ada upaya sistematis kecil untuk memeriksa harapan ini.

Di bawah tekanan dari rumah putih, komisaris baru meninggalkan pakta dengan

serikat. Serikat pekerja mulai pertempuran, lama berlarut-larut dengan manajemen untuk

kontrol atas proses implementasi. Pertempuran ini sering mengakibatkan kesaksian kongres

publik menantang klaim manajemen pelayanan ditingkatkan, kualitas, dan produktivitas.

Dalam pandangan tenaga kerja, manajemen SSA memberikan tekanan yang berlebihan pada

karyawan untuk bekerja lebih cepat untuk membuat program modernisasi terlihat bagus.

"Serikat buruh dan karyawan menantikan modernisasi sistem," menurut Rose Seaman,

seorang SSA klaim orang perwakilan dan pengawasan untuk SMP Federasi Amerika

Pemerintah Karyawan (AFGE), tetapi "sistem modernisasi tidak pernah disampaikan.

Sebaliknya ada tekanan besar pada repetisi klaim untuk melakukan fungsi administrasi sistem

tidak dapat melakukan, dan untuk mengubah catatan sehingga waktu pengolahan yang

berkurang.

Kantor Akuntan Umum (GAO), menanggapi permintaan Fom Gedung Pemerintah

Komite Operasi (Rep Jack Brooks, Demokrat dari ketua Texas), menerbitkan laporan yang

sangat kritis banyak kebijakan pengadaan SSA's. Dalam salah satu laporan yang dikeluarkan

pada tahun 1986, GAO menuduh bahwa SSA gagal untuk membangun kembali perangkat

lunak atau untuk mengembangkan arsitektur database yang benar. Dalam laporan lain tahun

1987, GAO mengklaim bahwa baru SSA's Klaim Modernisasi Software akan menangani

hanya 2 persen dari beban kerja (hanya aplikasi awal untuk pensiun dan tidak pemrosesan

aplikasi atau perubahan postentitlement). Laporan itu mencaci SSA untuk droping

modernisasi proses postentitlement yang menyumbang 94 persen dari transaksi harian SSA.

manajemen SSA panas GAO membantah tuduhan itu, tetapi kemunduran dalam perangkat

lunak menjadi senjata utama oppoenents SMP. GAO menyerukan penghentian dalam

pengadaan. Hampir tidak menolak dan mulai membeli 40.000 terminal destop berwarna.

Sebuah tinjauan SMP oleh Kantor Teknologi Assessment (OTA), sebuah lembaga

penelitian kongres, menyimpulkan bahwa Kongres dan Gedung Putih SSA semua harus

disalahkan atas kegagalan SSA's. Gedung Putih itu disalahkan untuk mencari prematur

pengurangan tenaga kerja besar sebelum sistem baru berada di tempatnya. Hal itu juga

menyalahkan untuk melanjutkan campur tangan politik di agen dan kegagalan untuk

manajemen Dukungan senior. Kongres disalahkan untuk jatuh untuk memahami kerumitan

program SSA dan sifat jangka panjang dari perubahan total sistem. Selain itu, OTA

menyalahkan hukum pengadaan baru untuk memperlambat dan menyulitkan pembelian

perangkat keras baru.

OTA menunjuk sejumlah kesalahan di SSA. Dari awal SMP, SSA gagal untuk

memikirkan kembali metode yang melakukan bisnis. SMP pada dasarnya berusaha untuk

mengotomatisasi struktur organisasi dan cara melakukan bisnis yang didirikan pada 1930-an.

SSA gagal, misalnya, mempertanyakan peran 1300 kantor lapangan - apakah mereka benar-

benar dibutuhkan dalam sehari jaringan luas dan mikrokomputer? Haruskah utama SSA's file

data akan terpusat di Baltimore? SSA gagal untuk memikirkan kembali arsitektur dasar dari

operasi mainframe terpusat di Baltimore melayani seluruh negeri. Mengapa tidak struktur

yang lebih desentralisasi? Mengapa tidak minicomputer di setiap kantor distrik? OTA juga

menunjuk kegagalan SSA untuk mengembangkan software baru secara waktu dan arsitektur

database baru. Ini terasa kekurangan ini, terutama dalam perangkat lunak dan basis data pada

akhirnya akan datang menghantui SSA sana setelah. Di SMP umum tidak memiliki visi untuk

masa depan sekitar yang bisa membangun sebuah arsitektur informasi yang kuat baru.

GAO, OTA dan tenaga kerja iklan percaya bahwa apapun yang terjadi peningkatan

produktivitas dari tahun 1982 sampai 1988 sebagian besar dihasilkan dari kemerosotan

pengurangan tenaga kerja dalam layanan dan meminta karyawan yang tetap bekerja lebih

keras, daripada setiap hasil teknologi per se. meskipun survei publik yang diterbitkan oleh

SSA menunjukkan masyarakat umum berpikir SSA melakukan pekerjaan baik, survei

karyawan kantor lapangan dan manajer dengan pengetahuan langsung terhadap situasi thr

menunjukkan penurunan kualitas pelayanan, kinerja karyawan, dan moral.

Sebagai level karyawan menurun, manajer mengeluh dalam wawancara bahwa "beban

kerja adalah menindas," mengingat hari di tahun 1960-an ketika klien baris dikelilingi kantor

SSA. Meskipun manajer memuji perangkat lunak klaim modernisasi baru, pusat Teleservice,

dan teknik pra- wawancara yang memungkinkan administrasi untuk menjawab pertanyaan

dari klien menggunakan query online, pengurangan secara keseluruhan dalam angkatan kerja

menaruh beban "menghancurkan personil Kantor kabupaten. "Karyawan dan manajer

melaporkan banyak manajer yang paling mampu dan wakil klaim meninggalkan SSA untuk

sektor swasta atau pekerjaan govrment lain sebagai kondisi kerja yang memburuk.

Untuk para kritikus SSA telah membuat beberapa perbaikan dalam pelayanan dan

pengolahan, tetapi menghasilkan awal dalam rencana SMP dan sebagian besar hasil

pembelian perangkat keras dan perangkat lunak lama menjalankan lebih cepat. Apapun

kemajuan dalam produktivitas terjadi melakukannya dengan mengorbankan karyawan dan

pelayanan kepada klien.

Pada 1988, manajemen SSA mengakui bahwa SMP memang dua kali lipat ke $

diproyeksikan 1 miliar, tapi tahun 1988 rencana SMP benar-benar menghabiskan sedikit

kurang ($ 444 juta) dari perkiraan awal sebesar $ 500 juta Manajemen mengakui bahwa

waktu yang diperlukan untuk mencapai keadaan pengolahan seni telah diperpanjang hingga

1992, bahwa ada penekanan yang berlebihan pada perangkat keras, pengembangan perangkat

lunak yang lambat, dan bahwa agen pembawa atas saldo besar dana unbudgeted dari tahun ke

tahun (menunjukkan kesulitan dalam mengelola proyek dan dana yang dialokasikan) .

Bahkan, pengembangan perangkat lunak adalah empat tahun di belakang jadwal, dan

mendesain ulang database (yang disebut "backend" sistem) masih sedang dipertimbangkan

setelah lima tahun. Namun demikian, SSA telah didokumentasikan terus membaik dalam

beberapa ukuran layanan kepada penerima manfaat, banyak yang disebabkan oleh SMP.

25 persen penurunan klaim RSI waktu proses.

Penurunan kecil di DI klaim waktu proses (2,2 hari).

Tingkat tinggi dan meningkatkan akurasi klaim RSI (95,7 o 97,2 persen).

Penurunan 41 persen dalam waktu SSI pengolahan.

Penurunan 7 persen dalam waktu SSI buta / pengolahan dinonaktifkan.

Penurunan 47 persen di RSDI (Pensiunan Korban Cacat Asuransi) perubahan waktu

status pengolahan.

Stabil biaya administrasi di RSI sejak tahun 1980 (1,1 persen dari manfaat).

Manajemen menunjuk perubahan kunci berikut dibawa oleh SMP. Manajemen

menyatakan bahwa seluruh SMP membawa peningkatan 25 persen dalam produktivitas.

Badan itu sekarang melakukan sedikit lebih "bekerja" pada tahun 1988 dibandingkan dengan

tahun 1982 tetapi dengan 17.000 karyawan yang lebih sedikit. SSA menciptakan komisaris

wakil baru untuk pengembangan sistem dan mengangkat status sistem dalam organisasi ke

tingkat manajemen senior. Manajemen mencatat bahwa SMP telah membuat kemajuan besar

dalam bidang tertentu programnya.

Kapasitas Hardware Upgrade.

Antara 1982 dan 1988 SSA meningkatkan kapasitas pemrosesan dua puluh kali lipat,

dari 20 MIPS menjadi total 400 MIPS, menggantikan komputer usang dibeli tanpa tawaran

bersaing dengan hardware yang disediakan oleh tiga produsen secara kompetitif.

Sistem Operasi dan Program Manajemen (SOMP)

Fasilitas pengolah pusat di Baltimore dikembangkan standar pekerjaan penjadwalan

yang efisien dan prosedur penanganan kaset dan dokumen sehingga 95 persen dari prosesnya

selesai tepat waktu.

Komunikasi Data Utility Program (DCUP).

Dalam SMP jaringan lebih dari 500.000 perangkat telah terinstal nasional, dengan

tujuan menempatkan terminal di desktop setiap perwakilan klaim's. Kapasitas Jaringan

meningkat dari 1200 karakter perdetik di 1982-7000 karakter perdetik pada tahun 1988.

Rekayasa Perangkat Lunak

SSA membuat kemajuan besar mendesain ulang perangkat lunak untuk program

pensiun. Sekarang juta orang pensiunan dapat memulai proses klaim atau menanyakan

tentang account mereka menggunakan Teleservice 800-nomor atau memiliki perwakilan

klaim memulai klaim on-line dari kantor kabupaten. Pada tahun 1982 kemampuan ini bahkan

tidak dibayangkan. Mengembangkan sistem interaktif tersebut untuk memberikan layanan

yang dibutuhkan sama sekali kode baru, perangkat lunak lama tidak dapat diselamatkan.

Integrasi Database.

SSA dikonversi 500.000 gulungan tape untuk DASDs yang lebih modern. Semua file

master dikonversi ke dalam suatu disk, sehingga memungkinkan untuk menangani lebih dari

2 juta pertanyaan per hari langsung on-line. SSA mengembangkan sendiri in-house datanya

sistem manajemen yang disebut Master Data Metode Akses (MADAM) untuk menangani

semua on-line dan akses ke file master batch SSA. Namun, data masih diatur menurut

wilayah program utama. SSA belum mengembangkan sebuah database yang terintegrasi

untuk semua atau bahkan beberapa program utama yang bisa menyediakan "manusia

seutuhnya" melihat klien SSA. Kesulitan utama adalah memutuskan arsitektur database

keseluruhan yang dapat mengintegrasikan informasi dari wilayah program utama.

Section III : Perencanaan strategis dan perencanaan sistem informasi SSA

SSA menerbitkan sebuah Rencana Strategis Instansi (ASP : Agency Strategic Plan) yang baru pada

1988.Rencana tersebut diupdate pada 1991 untuk memasukkan visi masa depan instansi yang lebih

luas. Prioritas strategis ASP diambil untuk perbaikan dalam akses klien untuk SSA, proses banding,

dan proses cacat,gerakan menuju instansi paperless, dan pembentukan struktur desentralisasi

pengolahan data.

Pada agustus 1990 Renato A dipentima mengambil alih deputi commisioner dari sistem. Dipentima

memperkenalkan Rencana sistem informasi 7 tahunan (ISP : information system Plan) untuk

mendukung ASP. ISP diudate pada 1992-1993.

ISP adalah planning jangka panjang SSA untuk mengatur sistem informasi sesuai perkembangan

instansi pada 1990. Tujuan utamanya adalah untuk mendukung ASP dengan membangun sebuah

lingkungan sistem yang memberikan service pada publik dan pengguna SSA. Prioritas strategi jangka

panjang termasuk membangun ketidakmampuan proses, proses aplikasi dan akses publik ke SSA

dengan menjadikan SSA sebagai instansi paperless dengan folder elektronis dan memberikan sebuah

arsitektur proses kooperatif . ISP dirancang untuk menjadi sebuah rencana yang kontinu yang bisa

selalu di update.

Kedua rencana dihadapi SSA saat peralihan ke abad 21. Total beban kerja SSA bertambah 26 persen

antara thn 1990-2005, ada pembatasan pendanaan untuk inisiatif baru, seiring dengan meningkatnya

permintaat layanan publik. Akhirnya kebanyakan klien SSA memilih untuk mengunjungi kantor SSA,

hari ini mereka lebih suka menjalankan bisnis melalui telepon dan mereka mendapatkan kecepatan

yang sama, service efisien yang mereka terima pada sektor privat. SSA harus meningkatkan sistem

untuk mengatasi meningkatnya beben kerja tanpa harus menambah karyawan, empertahankan biaya

yang rendah karena rendahnya sumberdaya keuangan. Jumlah lapangan dan pekerja operasional sudah

berkurang sejak 1980 dan pekerja yang tersisa membutuhkan teknologi baru untuk menangani

meningkatnya beban kerja.

SSA masih menggunakan sistem mainframe terpusat pada bagian utamanya, baltimore

menghubungkan 39000 termina pada kantor dan pusat teleservice melalui SSaNet dan jaringan utama

SSA. Rencana sistem informasi digunakan untuk memindahkan SSA kepada arsitektur terdistribusi,

mmusatkan terminal pada komputer mainframe untuk aplikasi program yang membawa layanan pada

klien SSA. Fungsi-fungsi bisnis terpilih diantara server dan prosesor lokal.

mayoritas pekerja SSA akan mengguakan komputer LAN dengan multiple software yang berjalan

pada platform antara mainframe ke microcomputer. Database didistribusikan.Efisiensi yang lebih

besar akan dihasilkan dari proses pendekatan sumber data dan informasi ke user.

Modernisasi teknologi SSA diaplikasikan untuk IWS/LAN (Intelligent Workstation/LAN). IWS/LAN

ditujukan untuk memindahkan SSA ke lingkungan komputer yan lebih desentralisasi dengan

mengganti terminal SSA dengan 95000 PC yang disusun dalam model jaringan Token ring. LAN

memberikan staff SSA kebebasan lebih dalam berkomputer dan kemampuan untuk word processing,

sharing data dan untuk bertukan email. Mereka dihubungkan dengan jaringan utana,SSANet.

Dengan prosess distribusi dan penyimpanan data pada level dimana pekerjaan dilakukan, jumlah data

yang diakses dan volume dari trafik jaringan harus dapat diminimalisasi, meningkatkan waktu repon

untuk banyak beban kerja. Penyusunan ini akan menyebabkan otomatisasi dari berbagai fungsiyang

tidak efektif dilakukan pada sebuah mainframe atau secara praktis dilakukan pada sebuah OPC,

memberikan SSA kapasitas komputer untuk menangani meningkatnya beban kerja.

Pusat komputer SSA di Baltimore akan terus mensuplai tenaga pemrosesan mainframe. SSA

menggunakan software mainframe yang sudah ada untuk program -program seperti security tambahan

yang sudah tersedia secara otomatis, dengan pc menirukan terminal-terminal lama. Pusat komputer

SSA di Baltimore akan terus mensuplai tenaga pemrosesan mainframe. SSA menggunakan software

mainframe yang sudah ada untuk program -program seperti security tambahan yang sudah tersedia

secara otomatis, dengan pc menirukan terminal-terminal lama.

Tapi sebagaimana aplikasi yang ditulis ulang, PC akan bekerja lebih pada pemrosesan dan mainframe

akan menjadi database server. SSA telah meyakinkan bahwa inplementasi dari IWS/LAN penting

untuk menyediakan suatu infrastruktur komunikasi elektronik dan rekayasa ulang dan untuk

mencegah masalah-masalah dan pengeluaran-pengeluaran yang dihasilkan dari kerusakan terminal-

terminal yang ada.

SSA telah mengganti banyak aplikasi dengan sistem online interaktif, mulai prosess title II. Akhirnya

title XVI, cacat dan pada proses title II akan dilaksanakan online, pada tahun 2000, SSA

mengharapkan untuk merubah sistem utamanya ke lingkungan interaktif menggunakan teknik update

tampilan, yang dari perspektif user digunakan untuk mengupdate master record secara online. Ekspert

sistem ,seperti suatu aplikasi disediakan untuk menyediakan jawaban pada pertanyaan melalui

telepon, akan membantu mengurangi proses manual.

Meskipun database akan didistribusikan melalui sistem komunikasi SSA DBMS komersial belum

cukup untuk mengatasi kebutuhan spesifik SSA di bawah lingkungan proses terdistribusi. SSA

berencana untuk mementau kinerja DBMS komersial untuk pertimbangan di masa depan.

SSA mengurangi pengeluaran transmisi dengan menggunakan sistem telepon switch, untuk

mengintegrasikan akses jaringan bila memungkinkan, hal ini akan menyediakn koneksi yang akan

disharing oleh Voice service, video teleconference,fax, interkoneksi LAN dan SSANet. Perencanaan

komunikasi SSA akan menggunakan standar OSI, menetapkan protokol yang sesuai, interface dan

teknologi jaringan untuk memperoleh interoperabilitas.

Point SSA adalah untuk perbaikan berbagai layanan yang dihasilkan dari inisiatif system. Sejumlah

800 nomor telepon sekarang meneriman 300000 panggilan perhari. 70% bayi di amerika dihitung saat

lahir, menghilangkan keharusan untuk membuat aplikasi terpisah untuk SSN (social Security

Number). Kios dipasang di beberapa lokasi untuk memberikan layanan informasi publik.

Apakah Teknologi Terdistribusi Cukup?

Pada musim semi tahun 1994, Office of Technology Assessment - Kantor Penilaian

Teknologi merilis sebuah laporan yang menyatakan bahwa $ 1,1 milyar migrasi SSA lima tahun dari

mainframe ke komputasi client / server kedengarannya teknis, tetapi di depan pemahaman lembaga

tentang bagaimana menggunakan workstation cerdas dan LAN untuk meningkatkan layanan

pengiriman. Laporan OTA mengulangi keprihatinan yang didapat oleh GAO bahwa SSA tak mungkin

untuk mewujudkan manfaat tersebut secara signifikan karena hal itu tidak berhubungan dengan

strategi usulan teknologi untuk menentukan perbaikan jasa pengiriman. GAO mempertanyakan

rencana SSA untuk melaksanakan IWS / LAN sebelum menentukan perbaikan pelayanan yang

dihasilkan dari teknologi ini. OTA mencatat bahwa SSA telah membuat suatu "upaya yang baik "

untuk merestrukturisasi layanan, tetapi lembaga itu memiliki "prioritas instalasi menurut kebutuhan

layanan pengiriman dan operasional SSA saat itu – intinya mengotomatisasi perbaikan marjinal

dalam status quo. OTA percaya bahwa SSA menginginkan untuk mencakup kliennya, perwakilan

tenaga kerja dan individu dengan pengalaman layanan pengiriman elektronik ke dalam proses

perencanaan dan memerlukan untuk merekayasa ulang proses bisnis secara dramatis guna

meningkatkan layanan. OTA percaya SSA tidak cukup hanya melakukan analisis biaya dan manfaat

dari otomatisasi, termasuk IWS / LAN, dan dampak otomatisasi terhadap tujuan kinerja tertentu.

OTA menunjukkan bahwa beban kerja SSA meningkat, ditambah dengan pengurangan staf

dari perampingan pemerintah lebih lanjut, dapat mengancam kemampuan SSA untuk memberikan

tingkat pelayanan yang diharapkan oleh Kongres dan publik lagi. Penggunaan 800 nomor telepon,

komponen kunci dari strategi pelayanan pengiriman SSA saat ini, merupakan kelebihan beban

selama periode puncak (kebanyakan penelepon menerima sinyal sibuk pada upaya panggilan

pertama mereka).

OTA juga mempertanyakan kelayakan mengelola lingkungan komputasi terdistribusi besar

dari fasilitas tunggal di Baltimore. Wakil Komisaris DiPentima menanggapi dengan mencatat bahwa

itu adalah tantangan besar untuk mempertahankan jaringan sedemikia besar dan memantaunya

secara terpusat. Jika SSA memonitor jaringan lokal, maka diperlukan 2000 manajer LAN. Jaringan

terpusat yang dikelola telah mampu memproses 20 juta transaksi per hari dengan 99,99 persen

waktu hidup.

OTA merekomendasikan bahwa SSA menerima dana untuk reengineering pengiriman dan

perencanaan pelayanan sehingga badan tersebut berpartisipasi dalam pengiriman elektronik

cakupan pemerintah dan pilot proyek seperti:

• Meningkatnya penggunaan bebas pulsa 800 nomor telepon untuk pengiriman layanan

• pertukaran data elektronik untuk laporan pengajuan pendapatan oleh bisnis

• deposit langsung secara elektronik untuk pembayaran manfaat

buletin Elektronik dan jaringan untuk menyediakan informasi tentang SSA

• Multi-program manfaat pengiriman elektronik di mana satu kartu bisa digunakan untuk

memperoleh pembayaran manfaat Social Security, Medicaid, dan kupon makanan

• elektronik record Terpadu untuk penerima SSA, menyediakan "folder elektronik" tunggal bukan file

elektronik dan kertas terpisah

• penentuan cacat otomatis untuk merampingkan penentuan kualifikasi medis awal dan

berkelanjutan untuk manfaat asuransi cacat

Dalam upayanya terhadap pengolahan paperless, SSA bekerja sama dengan Pitney Bowes

pada pilot sistem pengajuan elektronik untuk bisnis kecil. usaha kecil akan dapat file formulir pajak

tahunan mereka W2 di internet. Jika berhasil, upaya pengajuan elektronik dapat menggantikan 62

juta bentuk kertas yang SSA terima setiap tahun dari usaha kecil dan mengurangi beban kerja

operasi pusat data SSA di Wilkes Barre. (Perusahaan dengan lebih dari 250 karyawan sudah secara

file elektronik, meskipun tidak melalui internet)

Kebanyakan permintaan benefits estimates tersebut dibuat pada formulir kertas yang

membebani SSA sekitar $ 5,23 untuk masing-masing prosesnya. Kongres telah memerintahkan

badan untuk memberikan benefits estimates tahunan bagi setiap pekerja lebih dari 25, sebesar 123

juta orang, pada tahun 2000. SSA bereksperimen dengan menggunakan web untuk memberikan

informasi ini secara online hampir tanpa biaya. Wajib Pajak dapat menggunakan website SSA untuk

mendapatkan perkiraan on-line tentang manfaat pensiun mereka.

Penghematan akan signifikan, namun inisiatif tersebut jug memiliki potensi ancaman bagi

privasi individu. Untuk mengakses data melalui Web, individu harus memberikan nama mereka,

Social Security Number, tanggal dan tempat lahir, nama gadis ibu, dan alamat e-mail mereka. Kode

verifikasi akan diminta untuk memperoleh perkiraan manfaat online. Meskipun pejabat SSA percaya

situs Web mereka aman, mereka memperingatkan pengguna bahwa mereka tidak bisa menjamin

bahwa informasi yang dimasukkan oleh pengguna tidak dapat disadap oleh orang lain dan didekripsi.

Warga masih dapat menerima estimasi manfaat dan catatan laba mereka yang dilaporkan melalui

surat.

Jasa rekayasa ulang mulai harus dibayar. SSA sedang digambarkan sebagai agen federal

yang memberikan pelayanan terbaik kepada pelanggan, memenangkan pujian dari Wakil Presiden Al

Gore dan pakar bisnis rekayasa, Michael Hummer. Tapi layanan tingkat tinggi ini dapat

dikompromikan jika agensi tidak menyelesaikan masalah tahun 2000 nya..

SSA adalah salah satu instansi pemerintah pertama yang mengatasi masalah tanggal,

membuat perubahan tanggal menjadi bagian dari perawatan berkala sejak 1989. SSA mencetak

sekitar 45 juta cek per bulan, yang mewakili $ 3-400 mengalir tahunan ke dalam ekonomi AS.

Menurut Judy Draper, direktur proyek untuk tahun 2000, "Kita tidak bisa tidak memperbaikinya."

Tapi SSA tidak akan berada dalam kondisi vakum. Bahkan jika semua program tersebut diperbaiki, ia

akan menerima dan mengolah data Administrasi Veteran dan Departemen Keuangan. Masalah

tahun 2000 tidak akan diselesaikan sampai semua sistem yang berhubungan dari lembaga federal

lainnya juga dibenahi.

Banyak yang telah dipelajari oleh SSA tentang kesulitan pengembangan sistem yang dapat

memenuhi kebutuhan bisnis yang senantiasa berubah. Manajemen telah belajar bahwa

pengembangan teknologi informasi baru tidak secara otomatis diterjemahkan ke dalam karyawan

lebih sedikit, terutama bila volume transaksi yang meningkat. Dapatkah SSA terus untuk

mendesentralisasikan? Akankah infrastruktur informasi sistem SSA mempertahankan tingkat

pelayanan yang diharapkan Kongres dan publik? Ini hanya beberapa pertanyaan sulit yang dihadapi

SSA ketika bergerak ke abad kedua puluh satu.