METHODOLOGIES FOR PURCHASED

SOFTWARE PACKAGES

Sistem Informasi Manajemen

Kelompok II

Yayang Pande Maulana (041524253009)

Fitriyah Kusuma Dewi (041524253013)
Henry Novirga T (041524253017)
Carissa Cindi (041524253020)
Dwi Rendra (041524253022)
Have Zulkarnaen (041524253026)
Agustina Cahyaning W. (041524253027)

Program Studi Magister Akuntansi

Fakultas Ekonomi dan Bisnis
Universitas Airlangga
Surabaya
2016
Keputusan Membeli Atau Membuat
Pilihan antara mebuat aplikasi kustom atau pembelian (atau leasing) perangkat lunak
paket-a make-orbuy pengambilan harus dilakukan bersama-sama oleh para manajer yang
membutuhkan perangkat lunak dan profesional IS yang memiliki pengetahuan untuk menilai
manfaat teknis dan risiko. Untuk organisasi IS personil, tiga keuntungan yang paling jelas
dari kemasan perangkat lunak (1) penghematan biaya, (2) kecepatan lebih cepat dari
implementasi kualitas perangkat lunak, dan (3) staf internal yang tersedia untuk bekerja pada
aplikasi lain yang tidak dibeli. Sebuah paket perangkat lunak biasanya biaya kurang dari
solusi kustom karena vendor software akan menjual paket untuk banyak organisasi. Artinya,
perusahaan yang memperoleh software akan berbagi pengembangan dan peningkatan biaya
paket. Beberapa biaya tambahan untuk kustomisasi oleh staf internal atau konsultan biasanya
diperlukan (Misalnya, untuk membuat judul laporan lokal, menggunakan companyspecific
nama data). Sebuah paket perangkat lunak juga biasanya dapat implementasikan lebih cepat
dari aplikasi kustom karena sudah ada; ini bisa menjadi keuntungan yang sangat penting. Ini
dapat menjadi penting ketika IT dan staf bisnis kurang memadai pengalaman dengan aplikasi,
sehingga membuat perkembangan proyek terutama berisiko. Sebuah paket mungkin lebih
disukai untuk mendukung inti, fungsi bisnis generik yang Anda organisasi tidak bersaing
dengan organisasi lain yang juga bisa memperoleh teknologi yang sama. Tentu saja,
keuntungan nyata berasal dari cerdas menggunakan paket cara pesaing tidak bisa. staf
internal kemudian dapat mencurahkan waktu mereka untuk membuat semua aplikasi
beroperasi dan mengembangkan aplikasi yang memerlukan pengetahuan lokal atau memiliki
keunggulan kompetitif.
Isu-isu lain yang berperan dalam membuat keputusan membili atau membuat yang
membeli keputusan adalah kelayakan finansial utama atau vendor yang diinginkan, apakah
perangkat lunak sesuai dengan yang dipilih perangkat lunak sistem organisasi, apakah vendor
memiliki visi untuk peningkatan paket yang kompatibel dengan masa depan organisasi
(bukan hanya saat ini), keandalan vendor dalam memberikan baru rilis tepat waktu, dan total
biaya kepemilikan (yaitu, mempertimbangkan bukan hanya biaya pembelian tetapi juga
jangka panjang biaya untuk mempertahankan dan meningkatkan perangkat lunak-an terutama
faktor penting yang perlu dipertimbangkan dengan paket open-source, yang kita bahas nanti
dalam bab ini).
Metodologi Pembelian
Meskipun pada pandangan pertama tampaknya relatif mudah untuk pembelian paket
perangkat lunak, banyak contoh dari masalah pelaksanaannya muncul masalah karena sebuah
organisasi tidak mengerti apa yang harus dilakukan dan menginstal paket perangkat lunak
yang dibeli. Deskripsi kita tentang langkah-langkah pembelian mengasumsikan bahwa
persetujuan awal telah diterima untuk Sistem baru yang ukuran yang cukup untuk mendapat
penuh proses pembelian. Seperti yang akan kita bahas, paket Temukan harus menjadi
keputusan bersama antara bisnis manajer yang bisa menilai manfaat organisasi dan risiko dan
IS profesional yang dapat membantu menilai manfaat dan risiko dari teknis serta dukungan
terus-menerus perspektif. Perhatikan bahwa fokus kami adalah apa yang telah disebut sebagai
paket "khusus" yang menawarkan solusi untuk masalah bisnis tertentu, daripada produktivitas
pribadi suite (misalnya, Microsoft Office). diskusi kita juga berasumsi bahwa suatu organisasi
memiliki spesialis IS sendiri.

Langkah-langkah Pembelian
Template untuk langkah-langkah proses pembelian ditunjukkan pada Gambar 10.1.
Langkah-langkah untuk pembelian paket aplikasi masuk ke dalam tiga fase siklus hidup
diperkenalkan pada Bab 8: Definisi, Konstruksi, dan Implementasi. Dalam SDLC (SDLC)
metodologi dijelaskan pada Bab 9, spesifikasi sistem rinci (sistem) didokumentasikan dalam
Definition tahap; sistem ini dibangun pada tahap konstruksi; dan sistem terinstal,
dioperasikan, dan dipelihara di tahap implementasi. Karena pengembangan aplikasi
disesuaikan menggunakan proses SDLC historis datang pertama, proses untuk paket
pembelian disebut di sini sebagai dimodifikasi Pendekatan SDLC. Pada fase Definisi, sebuah
organisasi tidak hanya mendefinisikan kebutuhan sistem, tetapi juga kemudian menggunakan
ini persyaratan untuk mengidentifikasi vendor potensial dan solusi dan kemudian
mengumpulkan informasi yang cukup untuk dapat mengevaluasi mereka. Dibandingkan
dengan proses SDLC untuk perangkat lunak kustom, fase Definisi diperluas untuk mencakup
lima langkah-langkah tambahan, dimulai dengan membuat daftar pendek paket potensial.
Tahap Implementasi mencakup langkah-langkah yang sama seperti dalam SDLC.
Untuk sistem dibeli, namun, perangkat lunak Vendor mungkin sangat terlibat dalam Instalasi.
Selanjutnya, pemeliharaan paket biasanya tugas dilakukan oleh vendor. Negosiasi ini bagian
dari Oleh karena itu kontrak pembelian merupakan langkah penting.
Memulai Proses Pembelian
Serupa dengan keputusan untuk investasi aplikasi, organisasi menggunakan sejumlah
pendekatan untuk memutuskan apakah akan berinvestasi dalam sistem yang dibeli. Beberapa
organisasi tidak memerlukan rinci permintaan resmi untuk memulai penyelidikan dari
kemungkinan pembelian sistem karena ada asumsi bahwa sedikit IS sumber daya yang
diperlukan. Minimal, bisnis Manajer mempersiapkan dokumen yang menjelaskan secara
singkat yang diusulkan kebutuhan aplikasi dan menguraikan manfaat potensial bahwa
aplikasi akan memberikan kepada organisasi.
Sebuah perkiraan biaya tingkat tinggi untuk pembelian yang diusulkan akan perlu
dikembangkan dengan baik manajer bisnis dan IS masukan analis. Memperkirakan biaya
sistem melibatkan banyak lebih dari mengidentifikasi biaya pembelian paket calon.
Seperti ketika membangun sistem menggunakan SDLC, sebuah tim proyek sistem
harus ditetapkan dan diberi tanggung jawab untuk memperoleh perangkat lunak. Tim harus
termasuk perwakilan dari unit bisnis yang akan mengimplementasikan sistem, IS analis, dan
lainnya IS spesialis yang akan mengoperasikan dan mendukung sistem dikemas dan sistem
lain yang akan antarmuka dengan paket. Beberapa peran tim khusus akan dijelaskan
kemudian dalam bab ini.
 FASE DEFINISI
Dimulai dengan dua langkah yang sama seperti pada proses SDLC. Namun, lima
langkah-langkah tambahan yang khusus untuk proses pembelian.

1. Analisis kelayakan
Serupa dengan SDLC, yang Tujuan dari langkah ini adalah untuk menentukan apakah
yang diusulkan meliputi sistem ekonomi, teknis, dan operasional sudah layak. Ketika
membeli sistem, kelayakan membeli daripada membangun solusi sistem juga sedang
dipertimbangkan. Langkah ini karena itu akan mencakup Penyelidikan awal dari ketersediaan
dikemas sistem yang mungkin menjadi kandidat yang cocok, termasuk penyelidikan tingkat
tinggi dari fitur perangkat lunak dan kemampuan yang disediakan oleh vendor. Dalam hal ini
langkah yang lebih analisis biaya-manfaat rinci dilakukan untuk proyek penganggaran dan
pemantauan tujuan.

2. Persyaratan yang dibutuhkan

Persyaratan definisi adalah langkah penting dalam pendekatan SDLC. SDLC
penyampaian adalah spesifikasi rinci tentang apa sistem harus dilakukan di hal input itu harus
menerima, data harus menyimpan, yang proses-proses itu harus melakukan, output harus
menghasilkan, dan persyaratan kinerja yang harus dipenuhi. Syarat harus akurat, lengkap, dan
rinci karena digunakan untuk merancang dan memprogram sistem dan karena menentukan
kualitas sistem yang dihasilkan.
Ketika membeli sistem, langkah ini sama kritis. Dalam rangka untuk memilih paket
software terbaik, salah satu pertama harus memiliki setidaknya pemahaman konseptual
tingkat tinggi dari persyaratan sistem. Namun, di sini fokusnya adalah pada mendefinisikan
persyaratan fungsional dari sistem untuk tingkat yang diperlukan untuk mengembangkan
request for proposal (RFP) dari daftar pendek dari vendor. Persyaratan perlu untuk lebih
berkembang daripada persyaratan dasar digunakan untuk membangun prototipe tapi kurang
rinci dari persyaratan menimbulkan bawah proses SDLC ketika mereka digunakan untuk
merancang sistem yang sebenarnya. Penelitian telah menunjukkan bahwa ketidakpastian
tentang kebutuhan organisasi adalah signifikan penghalang untuk adopsi paket perangkat
lunak.
3. Buat Daftar Pendek Paket Cocok
Dalam langkah ini persyaratan organisasi digunakan untuk menghilangkan semua tapi
beberapa paket calon yang paling menjanjikan yang diidentifikasi pada langkah analisis
kelayakan. Sebagai contoh, paket harus dihilangkan jika mereka tidak memiliki fitur tertentu
yang diperlukan atau tidak akan bekerja dengan hardware yang ada, sistem operasi dan
manajemen database software, atau jaringan. penelitian lebih lanjut tentang vendor
kemampuan dapat dilakukan untuk menghilangkan vendor karena masalah yang dialami
dengan pengguna lain dari paket, sebuah vendor yang tidak memadai track record atau
ukuran perusahaan, atau lainnya kekhawatiran tentang kelangsungan hidup jangka panjang.
konsultan independen dengan keahlian pada tipe tertentu dari aplikasi atau mengkhususkan
diri dalam suatu industri tertentu juga dapat menjadi sumber daya utama di sini dan mungkin
bisa membantu tim proyek menghilangkan kandidat yang tidak pantas.

4. Menetapkan Kriteria Seleksi

Dalam langkah ini bisnis dan IS anggota tim harus bekerja sama untuk menentukan
kriteria yang relevan tentang paket calon dan vendor untuk memilih yang terbaik. Beberapa
kriteria dapat dikategorikan sebagai persyaratan wajib, sedangkan yang lain bisa
dikategorikan sebagai fitur yang diinginkan.
Beberapa daerah di mana kriteria (yaitu, di luar rinci biaya) harus dikembangkan
diperlihatkan pada Gambar 10.3. Untuk Misalnya, karakteristik bisnis vendor bisa termasuk
barang-barang seperti berapa lama vendor telah di bisnis perangkat lunak, jumlah karyawan,
keuangan laporan selama lima tahun terakhir, produk utamanya, yang pendapatan penjualan
software tahunan, dan lokasi penjualan dan kantor dukungan. kemampuan fungsional sistem
dikemas ini harus mencakup sejauh mana paket memungkinkan untuk beberapa pilihan dan
kemudahan yang itu bisa disesuaikan agar sesuai kebutuhan perusahaan menggunakan
parameter atau lainnya pendekatan yang tidak memerlukan sistem pengkodean.
Persyaratan teknis untuk dievaluasi mencakup perangkat keras dan perangkat lunak
sistem (sistem platform) diperlukan untuk efisien menjalankan aplikasi dan database
persyaratan untuk paket, serta kemudahan instalasi dalam lingkungan suatu perusahaan ini.
Ini Informasi memungkinkan seseorang untuk mengevaluasi seberapa baik paket akan sesuai
dengan standar organisasi saat ini untuk perangkat keras, software, dan jaringan. Jenis,
jumlah, dan kualitas dokumentasi yang juga harus dievaluasi, serta kualitas dan jumlah
vendor dukungan yang tersedia, termasuk pelatihan, konsultasi, dan perbaikan sistem.
 Selain merinci kriteria evaluasi, Pertimbangan harus diberikan untuk tindakan yang
akan digunakan dalam proses evaluasi. Hal ini tidak biasa untuk mengevaluasi paket
menggunakan skala dengan nomor (misalnya, 1 melalui 10) atau label kualitatif (misalnya,
luar biasa, baik, Rata-rata, adil, atau miskin). Jika skala dengan nomor yang digunakan,
masing-masing kriteria dapat ditugaskan berat penting, dan skor tertimbang dapat dihitung
untuk setiap evaluasi.

5. Mengembangkan dan mendistribusikan A request for proposal RFP (RFP)

RFP (kadang-kadang disebut permintaan untuk kutipan, atau RFQ) adalah dokumen
formal yang dikirim ke vendor potensial mengundang mereka untuk mengajukan proposal
yang menggambarkan paket perangkat lunak dan bagaimana itu akan memenuhi kebutuhan
perusahaan. dalam organisasi dengan sebelum software pengalaman pembelian, template
untuk RFP sudah bisa dikembangkan. Dimana ini akan sangat tergantung pada jenis paket
dan spesifik kebutuhan bisnis. Tim proyek menggunakan kriteria seleksi untuk
mengembangkan RFP. RFP memberikan informasi vendor tentang tujuan sistem dan
persyaratan, lingkungan di mana sistem akan digunakan, kriteria umum yang akan digunakan
untuk mengevaluasi proposal, dan kondisi untuk mengirimkan proposal. pertanyaan spesifik
mungkin perlu ikembangkan untuk menangkap karakteristik kinerja sistem, apakah kode
sumber yang disediakan, dan apakah organisasi pembelian diperbolehkan untuk
memodifikasi paket tanpa membatalkan garansi penjual. Selain harga informasi untuk paket
itu sendiri, biaya tambahan untuk pelatihan dan konsultasi perlu dipastikan. RFP bisa juga
dapat digunakan untuk menangkap informasi sejarah tentang paket, seperti tanggal rilis
pertama, tanggal nya revisi terakhir, dan daftar perusahaan di mana paket telah
diimplementasikan-termasuk informasi kontak untuk mendapatkan referensi dari perusahaan-
perusahaan ini. Langkah ini berakhir ketika RFP dikirim ke daftar pendek vendor berkualitas.
Selain mengevaluasi respon dari vendor dari proses RFP formal, dua jenis data
Koleksi umumnya dikejar, setidaknya untuk terkemuka paket calon. Pertama, demonstrasi
terkemuka paket biasanya dapat diatur. Selain itu, mungkin mungkin bagi vendor untuk
menginstal perangkat lunak pada komputer organisasi untuk beberapa waktu singkat untuk
memungkinkan test drive dari aplikasi. Dengan cara ini Anda dapat menjelajahi langsung
beberapa fitur yang tidak ada waktu di demo untuk menunjukkan dan yang dapat digunakan
oleh staf untuk menyelidiki potensi keanehan bahwa vendor staf cepat melewati selama
demo. Kedua, referensi dari pengguna dari paket perangkat lunak di perusahaan lain biasanya
diperoleh. masing-masing vendor mungkin diminta untuk memberikan daftar referensi, untuk
spesifikasi Anda, sebagai bagian dari RFP. Anda mungkin meminta referensi dari organisasi
berukuran sama, beberapa geografis dekat, yang memiliki campuran pengalaman (misalnya,
beberapa baru-baru ini dan beberapa pembeli jangka panjang), atau dari bisnis serupa. Anda
bahkan mungkin ingin berbicara dengan referensi yang memilih untuk tidak untuk membeli
paket. Salah satu teknik sangat efektif adalah untuk meminta vendor untuk memberikan
nama-nama pengguna serta IS spesialis untuk setiap organisasi pelanggan pada daftar
referensi mereka. anggota satgas kemudian dapat membagi nama-nama dengan, misalnya, IS
spesialis menghubungi mereka rekan-rekan di perusahaan yang sudah mengimplementasikan
paket. kunjungan ke satu atau lebih perusahaan ini mungkin juga mungkin. Evaluasi
dukungan vendor, konsultasi, dan pelatihan jasa juga dapat diperoleh dari sumber-sumber ini.
Anda perlu memahami situasi dengan organisasi referensi untuk memahami bagaimana
mengevaluasi pengalaman mereka. Sebagai contoh, sebuah referensi di mana paket
disodorkan pada pengguna dengan unit TI kemungkinan akan memberikan komentar yang
berbeda dari satu referensi dari organisasi di mana paket itu dipilih oleh hati
Proses, seperti diuraikan dalam bagian ini. Berdasarkan semua informasi yang
disebutkan sebelumnya sumber, tim proyek perlu menilai seberapa baik kebutuhan
perusahaan sesuai dengan kemampuan yang tersedia paket. Ini merupakan langkah penting
yang Format harus mengikuti garis besar yang disediakan. membutuhkan baik bisnis dan
keahlian teknis. Hasil langkah proses ini juga akan memiliki konsekuensi yang luas untuk
keberhasilan proyek. Setelah perbedaan antara kemampuan paket ini dan kebutuhan
perusahaan yang diidentifikasi, tim perlu memilih cara terbaik untuk menangani perbedaan
ini untuk paket calon atas. Dengan asumsi bahwa perusahaan memutuskan bahwa itu masih
ingin berinvestasi di salah satu paket, ada tiga alternatif utama untuk memilih dari. Seperti
yang ditunjukkan di bagian bawah Gambar 10.6, perusahaan dapat mengubah prosedur
sendiri sesuai paket, menyelidiki kelayakan dan biaya memodifikasi paket, atau menerapkan
paket "sebagaimana adanya" dan bekerja di sekitar perbedaan. Merupakan faktor penting
ketika memilih antara ini alternatif sepenuhnya memahami perkembangan tambahan usaha
dan biaya yang akan diperlukan untuk memodifikasi paket untuk menyesuaikan dengan
kebutuhan perusahaan dan mengintegrasikannya ke dalam lingkungan perusahaan. alternatif
ini. Oleh karena itu perlu dibuat bekerjasama dengan intern IS spesialis dan vendor dari calon
top paket dalam rangka untuk memastikan bahwa sejauh mana perbedaan havebeen
sepenuhnya diidentifikasi dan bahwa kelayakan dan tidaknya memodifikasi paket yang
diberikan telah sepenuhnya dipertimbangkan. Jika modifikasi sistem adalah alternatif, yang
rencana untuk mana organisasi akan bertanggung jawab untuk pemrograman perubahan dan
total biaya dari perubahan ini perlu dipertimbangkan. Lebih lanjut, dampak dari
memodifikasi paket perlu dievaluasi untuk bukan hanya proyek sistem awal tetapi juga untuk
selanjutnya pemeliharaan dan paket upgrade proyek. Sebagai contoh, banyak perusahaan
yang membeli kompleks besar hari ini paket sistem perusahaan, seperti sistem ERP, yang
disarankan untuk menghindari pemrograman ulang bagian-bagian dari paket di Untuk
menghindari biaya terus memodifikasi baru rilis dari paket di masa depan (lihat bagian
selanjutnya berjudul "Kasus khusus: Paket Enterprise System").
Sebaliknya, banyak perusahaan pembelian telah memutuskan untuk mengambil
alternatif tengah pada Gambar 10.6: Ganti Prosedur. Artinya, mereka memutuskan bahwa
lebih baik untuk perusahaan untuk mengubah prosedur sendiri untuk mencocokkan jalan
paket perangkat lunak beroperasi dari memodifikasi paket. Sebuah perusahaan mungkin
sebenarnya bahkan menemukan bahwa procedural asumsi dimasukkan ke dalam paket adalah
cara yang lebih baik melakukan hal-hal selain yang ditentukan oleh perusahaan selama
Persyaratan Definisi langkah dari proses. Ini bisa terjadi jika vendor software telah
bekerja dengan satu atau banyak organisasi dalam industri yang sama terkemuka untuk
mengembangkan paket perangkat lunak. Sebagai contoh, vendor paket ERP besar hari ini
mungkin telah bekerja dengan konsorsium industri untuk mengembangkan modul sekitar
industryspecific proses, dan kemudian vendor dapat memasarkan mereka paket sebagai
memiliki "praktik terbaik" untuk industry tertanam dalam paket perangkat lunak mereka.
Oleh karena itu tidak hanya keputusan untuk membeli sistem adalah komitmen untuk
membeli yang terbaik dari sistem yang tersedia tetapi juga komitmen untuk apa pun
perubahan organisasi (Kadang-kadang kompromi) perlu dilakukan untuk melaksanakan
sistem. paket perangkat lunak adalah solusi vendor untuk masalah yang dirasakan ada di
sejumlah besar perusahaan. Dalam banyak kasus, solusi mengimplementasikan Praktek
terbaik setidaknya terbaik bagi banyak organisasi. Dengan demikian, ada kemungkinan
bahwa perbedaan antara kebutuhan organisasi dan kemampuan paket akan ada. Sebelum
menyelesaikan pembelian keputusan, tim proyek harus memastikan bahwa manajer bisnis
yang relevan mendukung keputusan untuk membeli dipilih paket dan setuju bahwa mereka
akan melakukan apapun yang diperlukan untuk menerapkannya dengan sukses. Demikian
pula, proyek Tim harus memastikan bahwa spesialis IS setuju bahwa Sistem dapat beroperasi
dalam lingkungan saat ini dan bahwa mereka memuaskan dapat mendukung dalam rumah
seperti yang diperlukan. Bernegosiasi Kontrak kiriman dari tahap ini adalah kontrak hukum
dengan vendor perangkat lunak yang dipilih paket dan rencana rinci untuk sisalangkah siklus
hidup. Kontrak dengan vendor perangkat lunak menentukan tidak hanya harga software,
 jumlah lisensi, dan jadwal pembayaran tetapi juga spesifikasi fungsional, penerimaan-
prosedur pengujian, jadwal pengiriman yang proses, perlindungan rahasia dagang, perbaikan
dan pemeliharaan tanggung jawab, kewajiban karena kegagalan, diperlukan dokumentasi, dan
pilihan untuk mengakhiri perjanjian tersebut (Gurbaxani dan Whang, 1991). Elemen penting
lainnya kontrak adalah hak pelanggan untuk masa depan upgrade dari paket-termasuk biaya,
dan apakah upgrade dapat dilewati belum rilis sebelum akan tetap didukung oleh vendor. .

Negosiasi Kontrak
Negosiasi kontrak harus menjadi bagian integral dari proses pembelian. Ketika
bekerja dengan vendor untuk menentukan bagaimana mengurangi perbedaan antara
kebutuhan perusahaan dan kemampuan paket ', satu adalah sebenarnya prenegotiating
kontrak dengan vendor yang dipilih. Banyak organisasi memiliki spesialis pembelian
software yang bekerja dengan manajer proyek sistem dalam kontrak menulis dan negosiasi
langkah. Karena kontrak akan menjadi satu-satunya jalan jika sistem atau vendor melakukan
tidak melakukan seperti yang ditentukan, penggunaan seorang pengacara juga mengurangi
kemungkinan perselisihan hukum masa depan atau hilangnya klaim yang sah.
Setelah proyek ini berlangsung, Manajer harus cukup akrab dengan kontrak
kesepakatan untuk mengetahui apakah kebutuhan tak terduga untuk layanan penjual akan
memerlukan perubahan formal untuk vendor kontrak. Jenis kontrak juga berimplikasi risiko
tingkat perusahaan pembelian. Misalnya, di bawah kontrak harga tetap, pembeli tahu di muka
total harga yang akan dikeluarkan untuk produk tertentu dan penjual jasa. Di bawah tipe
biaya-penggantian kontrak, di mana pembeli setuju untuk membayar vendor langsung dan
biaya tidak langsung, perusahaan membeli mengasumsikan banyak risiko yang lebih besar.

Fase Konstruksi
Terdapat 3 tahap pada fase konstruksi, yaitu:
1. Desain sistem
Desain Sistem adalah tahap setelah analisis sistem dari siklus pengembangan sistem yang
mendefinisikan dari kebutuhan-kebutuhan fungsional, persiapan untuk rancang bangun
implementasi, menggambarkan bagaimana suatu sistem dibentuk yang dapat berupa
penggambaran, perencanaan, dan pembuatan sketsa atau pengaturan dari beberapa elemen
yang terpisah kedalam satu kesatuan yang utuh dan berfungsi, termasuk menyangkut
mengkonfigurasi dari komponen-komponen perangkat lunak dan perangkat keras dari suatu
sistem.
2. Pembangunan Sistem
Pembangunan sistem adalah penyusunan suatu sistem yang baru untuk menggantikan sistem
yang lama secara keseluruhan atau memperbaiki sistem yang telah ada
3. Uji Coba Sistem
Uji Coba Sistem adalah pengujian sistem yang telah terbentuk dengan menilai output dari
sebuah proses apakah sudah sesuai dengan yang diharapkan atau belum, apabila belum perlu
dilakukan perbaikan-perbaikan sistem hingga sistem benar-benar siap dipakai.
Terdapat 2 Strategi dalam pelaksanaan fase konstruksi, yaitu:
1. Membangun sendiri sistem
Membangun sendiri sistem memerlukan biaya yang besar dan waktu yang cukup lama, tetapi
hasil dari membangun sistem sendiri dapat menyesuaikan kebutuhan sistem sesuai dengan
harapan.
2. Membeli paket sistem
Membeli paket sistem terbagi menjadi 2, yaitu:
a) Membeli tanpa modifikasi
Membeli tanpa modifikasi tentu mengeluarkan biaya yang lebih sedikit, serta dapat langsung
dioperasikan tanpa memerlukan waktu yang banyak. Kekurangannya terkadang tidak benar-
benar sesuai dengan harapan namun masih dalam toleransi user.
b) Membeli dengan modifikasi
Membeli dengan modifikasi bisa jadi mengeluarkan waktu dan biaya yang lebih besar
dibanding dengan membangun sendiri, bisa juga lebih murah. Hal ini tergantung dari
kompleksitas modifikasi yang diharapkan user, apabila modifikasi sangat kompleks tentu
memerlukan waktu dan biaya yang besar baik dari mengkode ulang maupun uji coba sampai
sesuai harapan.

Fase Implementasi
Terdapat 3 tahap pada fase implementasi, yaitu:
1. Instalasi
Instalasi adalah proses pemasangan baik software maupun hardware menjadi satu kesatuan
sistem yang dapat digunakan. Proses instalasi meliputi perencanaan instalasi, pelatihan, data
cleanup, dan pembicaraan. Kesuksesan tahap ini bergantung pada komunikasi antara user dan
pengembang sistem terkait bagaimana penggunaan sistem baru
2. Operasi
Operasi adalah kegiatan menjalankan sistem yang sudah terinstal, kesuksesan dalam operasi
sistem baru tergantung kecepatan user dalam menyampaikan masalah kepada pengembang
sistem sehingga dapat sesegera mungkin memperoleh solusinya.
3. Pemeliharaan
Pemeliharaan adalah proses yang dilakukan untuk memperbaiki masalah-masalah yang
terjadi pasca implementasi, selain itu juga perubahan formulir yang diakibatkan oleh
perubahan aturan, adanya pengembangan sistem dari vendor untuk memberikan menu baru
dalam aplikasi, dll.

Project Team for Purchasing Packages

Manajer bisnis dan pengguna harus memiliki komitmen yang besar terhadap proses
bisnis dan prosedur dalam penerapan aplikasi. Akibatnya, tidak jarang bagi para manajer
bisnis yang akan diminta untuk mengambil peran manajer proyek dalam proyek sistem
aplikasi. Namun, karena keahlian IS masih diperlukan untuk mengelola aspek teknis
pelaksanaan paket, manajer IS juga perlu memainkan peran kepemimpinan proyek.
Perusahaan kecil yang tidak memiliki spesialis IS akan perlu bergantung pada vendor
perangkat lunak atau konsultan luar, atau keduanya.
Vendor perangkat lunak pada awalnya memberikan informasi tentang kemampuan
paket dalam menanggapi RFP. Vendor akan diminta untuk memberikan demonstrasi dan
berkonsultasi dengan pembeli tentang modifikasi sistem potensial atau antarmuka baru untuk
system yang akan digunakan. Vendor dikontrak untuk melakukan modifikasi paket sebelum
pelaksanaan untuk mengurangi ketidaksesuaian antara kemampuan sistem dengan kebutuhan
organisasi berdasarkan penilaian dari manfaat dan risiko dalam melakukannya. Vendor juga
bisa memainkan peran utama dalam sistem instalasi, serta memberikan dukungan
pemeliharaan untuk organisasi pembelian. Pada perusahaan besar juga dapat melakukan
kontrak dengan perusahaan konsultan (yang mungkin telah disertifikasi oleh vendor
perangkat lunak) sebagai mitra implementasi pihak ketiga pada proyek.
Karena ketergantungan awal dan berkelanjutan pada vendor software, adanya
spesialis kontrak dalam perusahaan menjadi penting untuk keberhasilan dari implementasi
sistem yang telah dikemas. Sebagai contoh, jika RFP dikirim ke vendor, spesialis pembelian
akan membantu mempersiapkan atau setidaknya meninjau dokumen RFP sebelum
didistribusikan ke vendor. Spesialis pembelian terampil dalam negosiasi kontrak yang dapat
mengurangi risiko bisnis keuangan dan lainnya. Misalnya, banyak dari kontrak mencakup
perjanjian khusus tentang tingkat pelayanan selama periode instalasi.
Dalam melakukan negosiasi kontrak diperlukan pengacara untuk mengawasi
persetujuan kontrak eksternal dengan vendor perangkat lunak. Semua perjanjian lisensi
terkait juga harus ditinjau dalam rangka untuk meminimalkan biaya yang terkait dan risiko
untuk bisnis.

Managing a Purchased System Project

 Proyek sistem yang dibeli dikatakan sukses apabila perusahaan telah memilih produk
dan vendor yang mampu memenuhi kebutuhan sistem perusahaan sekarang dan masa depan.
Hal ini memerlukan tim proyek yang efektif dengan anggota yang memiliki usaha dan
keterampilan teknis dan pengetahuan yang dibutuhkan, termasuk keterampilan dan
pengetahuan yang dibutuhkan untuk peran tim proyek. Manajer bisnis, pengguna, dan
spesialis IS harus menjadi bagian dari tim proyek untuk memastikan bahwa telah membeli
paket terbaik dari vendor terbaik dan telah mempertimbangkan risiko teknis dan bisnis yang
akan terjadi.
Hal yang perlu diperhatikan dalam mengelola siklus dari proyek system yang telah
dibeli yaitu pada langkah-langkah dalam tahap Definisi awal. Karena banyak kesalahan yang
dilakukan perusahaan ketika bernegosiasi dengan vendor yaitu tidak memperhatikan langkah
fungsional dalam tahap definisi kebutuhan. Tim proyek yang tidak melakukan pekerjaan
dengan baik dalam mengidentifikasi kebutuhan, maka mengakibatkan ketidakmampuan
dalam melakukan pekerjaan yang baik dengan menilai perbedaan antara kebutuhan
perusahaan dan kemampuan calon paket. Hal ini meningkatkan risiko jangka pendek dan
investasi jangka panjang, karena kontrak dengan vendor eksternal tidak mudah berubah
sebagai perjanjian proyek antara pengguna internal dan pengembang IS. Oleh karena itu
penting bahwa fase Definisi harus dilaksanakan dengan baik.
Anggota tim proyek memiliki tanggung jawab penting dalam pelaksanaan, bahwa
manajer bisnis representatif dan pengguna harus berkomitmen untuk tujuan proyek, jadwal,
waktu dan anggaran.
Keberhasilan fase Implementasi juga tergantung pada seberapa baik tahap Definisi
dilakukan, karena anggota tim menilai perubahan perusahaan yang dibutuhkan ketika berhasil
menerapkan system yang telah dibeli. Pengguna sistem diminta untuk membuat perubahan
signifikan dalam melakukan pekerjaan menyesuaikan diri dengan fitur paket. Hal ini
memerlukan langkah instalasi yang terencana di bawah kepemimpinan manajer bisnis yang
berkomitmen sangat berpengetahuan tentang perubahan yang dibutuhkan.
Keberhasilan proyek sangat tergantung pada kinerja pihak ketiga. Kualitas sistem
yang diterapkan akan tergantung tidak hanya pada kemampuan rekayasa perangkat lunak
vendor tapi juga pada seberapa baik perusahaan pembeli memahami kemampuan paket dan
pada kemampuan pelatihan dan instalasi dari vendor.

Keuntungan dan Kerugian dari Pembelian Paket Sistem

 Pada subbab ini akan menjelaskan terkait keuntungan dan kerugian pembelian sistem paket,
serta beberapa potensi keuntungan dan kerugian jangka panjang untuk membeli paket solusi
perangkat lunak. Adapun keuntungan dan kerugian tersebut antara lain :
1. Keuntungan yang didapat dengan membeli Paket Software :
a. Mengurangi waktu untuk mengimplementasikan paket sistem tersebut;
b. Biaya akuisisi lebih rendah secara keseluruhan;
c. Kualitas aplikasi tinggi;
d. Mengurangi kebutuhan akan sumber daya manusia terkait pengembangan sistem;
e. Adanya tranfer pengetahuan dari pihak vendor kepada pihak internal;
2. Kekurangan yang didapat dengan membeli Paket Sofware :
a. Risiko adanya kurangnya pengetahuan terkait paket sistem tersebut;
b. Risiko akibat luasnya perubahan organisasi yang diperlukan;
c. Ketergantungan awal dan berkelanjutan pada vendor

Keuntungan dari Pembelian Paket Sistem

Keuntungan utama adalah bahwa, dibandingkan dengan pengembangan aplikasi
disesuaikan, lebih sedikit waktu yang diperlukan untuk mengimplementasikan sistem. Namun
demikian, untuk sistem menengah, seluruh proses masih akan memerlukan beberapa bulan,
dan untuk skala besar implementasi perangkat lunak perusahaan (dengan paket seperti sistem
ERP), proses dapat memakan beberapa tahun untuk mengimplementasikan modul secara
cukup dari perangkat lunak untuk mencapai keuntungan bersih.
Keuntungan kedua adalah bahwa paket perangkat lunak implementasi bisa sangat
menarik dari sudut ekonomi. Misalnya, usaha kecil dapat memperoleh sistem akuntansi
lengkap untuk kurang dari $ 25.000, yang sangat rendah dibandingkan dengan biaya
pengembangan aplikasi disesuaikan yang sebanding. Dengan asumsi bahwa vendor memiliki
lebih dari 10.000 instalasi dari paket kecil ini ($ 250 juta pendapatan), vendor akan memiliki
insentif untuk menghabiskan jutaan dolar untuk meningkatkan paket di pemesanan untuk
mengeluarkan rilis baru. Semua orang keluar sebagai pemenang karena setiap pembeli telah
menelan biaya penghindaran dari pembelian paket, dan vendor membuat keuntungan yang
cukup besar untuk bertahan dalam bisnis dan memberikan upgrade dan dukungan layanan
lainnya secara berkelanjutan.
Keuntungan sementara ketiga adalah bahwa di rumah sumber IS bisa dibebaskan
untuk mengembangkan aplikasi misi kritis yang bisa memberikan perusahaan keuntungan
kompetitif jika paket perangkat lunak dapat diimplementasikan untuk proses yang relatif
umum yang tidak memberikan spesifik keuntungan strategis.
Dua keuntungan jangka panjang yang potensial adalah kualitas aplikasi dan infus
keahlian eksternal. Kualitas dari paket perangkat lunak mungkin jauh lebih baik
dibandingkan dengan sistem yang biasa, karena vendor mampu untuk menghabiskan lebih
banyak waktu dan usaha mengembangkan sistem dari perusahaan perorangan. Juga, paket
mungkin termasuk praktek atau pilihan praktik terbaik untuk berbagai situasi terbaik.
Dokumentasi dapat jauh lebih baik dari rumah dokumentasi khusus, dan rilis baru dari paket
mungkin menggabungkan perbaikan direkomendasikan oleh perusahaan yang menggunakan
sistem. Selanjutnya, setiap rilis biasanya diuji secara menyeluruh, termasuk tes beta dalam
organisasi klien.
Akhirnya, paket solusi adalah cara cepat untuk menanamkan keahlian baru baik
keahlian IT dan keahlian bisnis ke dalam organisasi. Mengingat kecepatan perubahan
teknologi, kebanyakan organisasi saat ini sulit untuk melatih dan mempertahankan personil
IS dengan keahlian baru, teknologi baru. Vendor perangkat lunak sering memiliki dana dan
motivasi untuk mengembangkan sistem yang menggunakan teknologi yang lebih baru. Paket
solusi untuk industri tertentu, atau sistem ERP yang besar, juga sering memiliki proses dan
prosedur terbaik di kelasnya tertanam dalam perangkat lunak. Dengan membeli perangkat
lunak, perusahaan juga dapat mengadopsi proses bisnis yang lebih baik.

Kerugian dari Pembelian Paket Sistem

Dua risiko proyek besar juga terkait dengan menerapkan paket yang dibeli. Salah satu
risiko adalah kurangnya pengetahuan paket. Pelaksanaan paket dapat membutuhkan pelatihan
signifikan bagi IS serta bisnis personil, yang meningkatkan biaya implementasi. Karena
organisasi relatif tidak paham dengan paket perangkat lunak, organisasi mungkin juga tidak
dapat cepat memanfaatkan kemampuan dari paket sistem yang telah dirancang dan
dikembangkan secara khusus oleh anggota organisasi. Beberapa organisasi juga membuat
kesalahan awalnya memodifikasi paket, atau menambahkan fungsi lain, hanya untuk belajar
kemudian bahwa paket bisa memberikan fungsi yang sama jika sudah diimplementasikan
secara berbeda.
Risiko proyek terkait lainnya adalah bahwa sejak pelaksanaan sistem dikemas sering
membutuhkan perubahan proses bisnis yang signifikan, itu adalah risiko proyek yang lebih
besar. Pengetahuan luas manajer bisnis dan keterampilan spesialis IS harus terlibat secara
signifikan dalam fase Definisi untuk memahami perubahan apa yang perlu dibuat organisasi.
Selain itu, sering adanya resistensi pengguna karena luasnya perubahan yang diperlukan
dalam rangka untuk melaksanakan paket solusi.
Kerugian jangka panjang adalah bahwa organisasi menjadi tergantung pada penyedia
TI eksternal tidak hanya untuk instalasi awal dan mungkin beberapa modifikasi paket tetapi
juga untuk pemeliharaan dari paket. Meskipun dalam banyak kasus ini bisa mengakibatkan
aliansi strategis nilai untuk keduanya penjual dan pembeli, yang pembeli mungkin tidak
sepenuhnya mengantisipasi biaya koordinasi terkait dengan pengelolaan hubungan penjual.
Sebagai tambahan, tentu saja, ada risiko bahwa vendor akan keluar bisnis atau menjadi tidak
responsif terhadap kebutuhan pembelian perusahaan. Ada juga bisa menjadi bahaya harga
jika vendor membuat sulit bagi pihak ketiga untuk bersaing untuk dukungan jasa.

KASUS KHUSUS: ENTERPRISE PAKET SYSTEM

Pada akhir tahun 1990-an sebagian besar perusahaan di Amerika Serikat dan di Eropa
telah melakukan investasi pada sistem perencanaan sumber daya (ERP). Sebagian Besar
perusahaan yang membeli sistem ERP ini berharap akan memperoleh manfaat bisnis seperti
pengurangan biaya, proses bisnis dapat berjalan dengan lebih efisien, dan kecepatan dalam
mematuhi persyaratan hukum. Salah satu manfaat binis utama terkait dengan pemanfaat
sistem ERP adalah memungkinkannya akses ke repositori tunggal data terpadu, yang mana
dalam pengambilan keputusan oleh manajemen lebih baik menggunakan data real-time.
Hal ini dilakukan dengan mendapatkan aplikasi bisnis pada platform yang sama, sistem ERP.
Karena kebanyakan sistem ERP yang dibangun untuk mendukung proses bisnis lintas
fungsional, menyebabkan sistem antar muka mulai dikurangi. Selanjutnya, modul ERP yang
dapat "dikonfigurasi" dapat digunakan oleh berbagai jenis perusahaan dalam industri yang
berbeda memungkinkan perusahaan-perusahaan yang memiliki sudah dilakukan proyek untuk
ulang bisnis mereka proses untuk sekarang melaksanakannya; membangun kustom sistem
untuk mendukung proses lintas fungsional baru akan memerlukan investasi sistem yang jauh
lebih besar lebih jauh waktu lebih lama.
Mengadopsi sistem ERP merupakan tanggung jawab utama bagi sebuah organisasi,
tentu saja ada potensi risiko dan biaya dari penggunaan ERP. Biaya pembelian sistem ERP ini
sangat mahal, ditambah lagi adanya kemungkinan memerlukan biaya dalam hal konfigurasi
dan instalasi kepada konsultan jika organisasi berniat untuk menggunakan ERP ini. Seperti
misalnya masalah paket, tetapi lebih karena sifat komprehensif ERP. Sebuah paket ERP
membatasi sebuah organisasi dengan kemampuan dari paket tertentu. Paket ERP dapat
menetapkan standar untuk platform untuk semua sistem yang akan antarmuka selain itu
sebuah organisasi menjadi akan sangat tergantung pada satu vendor.
Tugas penggelaran ERP paket, yang mencakup mematikan aplikasi warisan di
organisasi, adalah kompleks dan dapat berbahaya untuk melanjutkan operasi. Ini semua risiko
penting dan biaya, oleh karena itu, keputusan untuk memperoleh paket ERP dan bagaimana
 mengelola penyebaran yang sangat penting, yang mana organisasi harus mempertimbangkan
bahasa serta resiko dari penggunaan ERP ini.
Bagi perusahaan yang membeli sistem ERP, maka departemen sistem informasi (IS)
harus membentuk sebuah tim untuk melaksanakan proyek ERP ini, yang mana tim tersebut
bertugas melakukan konfirgurasi paket ERP dengan sebaik-baiknya, bukan hanya
mengembangkan aplikasi berbasis pada kebutuhan mereka namun juga sebagai pengguna
bisnis. Departemen IS dan personil tim proyek lainnya, serta sebagai pengguna bisnis, harus
dikirim ke kelas pelatihan, biasanya dilakukan oleh vendor perangkat lunak, sehingga mereka
dapat belajar mengenai paket perangkat lunak serta belajar kepada vendor baru mengenai
bahasa untuk menulis interface. Karena, sistem ERP adalah generik, produk setengah jadi, IS
dan personil lainnya harus belajar bagaimana untuk mengkonfigurasi perangkat lunak untuk
pilihan yang terbaik bagi organisasi Anda. Baru setelah itu keahlian "analis bisnis" juga
mungkin diperlukan untuk efektif mengelola langkah-langkah dalam proses pelaksanaan
proyek perangkat lunak.
Karakteristik lain dari proyek awal ERP adalah adanya ketergantungan terhadap
konsultan pihak ketiga yang bukan murapakan karyawan dari vendor perangkat
lunak,konsultan ini merupakan perusahaan konsultan Big Four atau yang lebih kecil.
Konsultan ini membantu organisasi agar cepat belajar bagaimana paket perangkat lunak
beroperasi dan bagaimana proses bisnis yang kompleks bekerja. Karena implimentasi paket
ERP memiliki lingkup dan kompleksitas yang besar, maka tantangan terbesar bagi organisasi
yang menerapkan ERP ini adalah sejauh mana organisasi bergantung kepada konsultan
eksternal untuk memimpin sebuah proyek ERP dan bagaimana untuk memastikan perusahaan
memperoleh pengetahuan yang dibutuhkan terus beroperasi dan "menyempurnakan"
konfigurasi setelah konsultasi dengan konsultan telah berakhir.
Baru-baru ini perusahaan konsultan melakukan instalasi ERP kepada perusahaan
kliennya dan dapat diandalkan untuk menjaga aplikasi ERP berjalan dan dipelihara serta
memberikan beberapa konsultasi atas penerapan ERP, namun terkadang implementasi proyek
awal ERP tidak berhasil meskipun menggunakan jasa konsultasi pihak ketiga. Menurut
Brown dan Vessey (2003), ada lima faktor yang harus dijalankan jika ingin proyek awal ERP
berjalan dengan baik:
a. Manajemen puncak terlibat dalam proyek, bukan hanya terlibat. Karena sistem perusahaan
menuntut perubahan secara mendasar dalam cara perusahaan melakukan nya proses bisnis,
eksekutif bisnis yang harus tampak aktif dalam pendanaan dan pengawasan proyek. Manajer
tingkat yang lebih rendah tidak akan memiliki pengaruh yang diperlukan untuk memastikan
 bahwa tidak hanya modul ERP dikonfigurasi untuk menyelaraskan dengan proses bisnis
terbaik dan dan bukan hanya sebagai solusi bagi perusahaan.
b. Pemimpin proyek adalah veteran, dan anggota tim adalah pembuat keputusan, karena
implementasi sistem ERP sangat kompleks, para pemimpin proyek harus sangat terampil dan
memiliki jejak record yang terbukti dalam hal memimpin sebuah proyek yang telah memiliki
dampak besar pada bisnis. Anggota tim yang mewakili unit bisnis yang berbeda dan berbeda
fungsi bisnis (misalnya, keuangan, pemasaran, manufaktur) perlu diberdayakan untuk
membuat keputusan atas nama unit atau fungsi yang mereka wakili. Jika anggota tim tidak
memiliki hak pengambilan keputusan, para pemimpin proyek kemungkinan besar tidak akan
dapat memenuhi tenggat waktu proyek yang telah disepakati.
c. Pihak ketiga mengisi kesenjangan dalam hal keahlian dan mentransfer pengetahuan mereka.
Seperti dijelaskan sebelumnya, sistem ERP biasanya dilaksanakan dengan bantuan third
(konsultan), serta terkadang sebagai vendor software. Keperluan terhadap keahlian dari jasa
konsultan tergantung dari pada keahlian dan pengalaman dari bisnis perusahaan membeli
sendiri dan pengalaman manajer TI. Jika tidak ada pemimpin proyek internaldengan
keterampilan manajemen proyek yang diperlukan,konsultan juga harus digunakan untuk
membantu mengelola proyek. Namun, sebelum konsultan meninggalkan, staf internal perlu
untuk memperoleh pengetahuan yang dibutuhkan untuk terus mengoperasikan sistem baru.
banyak organisasi mengembangkan perjanjian dengan konsultan yang secara eksplisit
merujuk pada transfer pengetahuan untuk internal yangStaf sebagai bagian dari kontrak
konsultan.
d. Manajemen perubahan melukan kerjasama dengan proyek perencanaan. Banyak pengadopsi
awal dari sistem ERP meremehkan kebutuhan sumber daya proyek untuk membantu
mempersiapkan usaha untuk melaksanakan baru
sistem. sistem ERP biasanya membutuhkan pelatihan tidak hanya dalam bagaimana
menggunakan sistem baru tetapi juga dalam cara untuk melakukan proses bisnis dengan cara-
cara baru untuk mengambil keuntungan dari kemampuan paket ini. Karena integrasi ketat
dari modul ERP, pekerja juga biasanya perlu belajar lebih banyak tentang apa yang terjadi
sebelum dan sesudah interaksi mereka sendiri dengan sistem. Perusahaan dengan masalah
paling sedikit di waktu pelaksanaan mulai merencanakan untuk ini jenis perubahan sebagai
bagian dari proyek secara keseluruhan kegiatan perencanaan. Perubahan mendasar yang ke
proses bisnis. Telah ditemukan bahwa lebih baik memodifikasi proses bisnis perusahaan
daripada memodifikasi software yang dibeli. tidak memodifikasi proses bisnis agar sesuai
dengan software ERP adalah alasan utama untuk kegagalan proyek ERP. Tidak semua sistem
 ERP diciptakan sama. Hal ini berakar pada beberapa industri
(Mis, manufaktur, perbankan), sektor (yaitu, umum atau pribadi), atau negara (misalnya, AS
atau Eropa). Dengan demikian, penting untuk memilih paket ERP yang didasarkan pada set
praktik terbaik dan proses bisnis yang dijalankan oleh perusahaan.

OPEN SOURCE SOFTWARE

Walaupun pergerakan open source dimulai dengan software sistem seperti sistem
operasi Linux, Web browser Firefox, dan sistem manajemen database MySQL, open source
sekarang dapat digunakan pada aplikasi software dan paket memungkinkan lainnya
(misalnya, untuk data pergudangan dan intelijen bisnis). Open source dapat diunduh dari
berbagai papan bulletin. Dengan open source, anda mendapatkan source code dan berhak
untuk memodifikasi. Tergantung dari lisensi untuk memperoleh software, jika mengubahnya,
anda mungkin diwajibkan membagi perubahan tersebut dengan pengguna software lainnya.
Walaupun aplikasi open source free, provider serta pihak ketiga menyediakan produk
serta layanan berbayar untuk perpanjangan produk dengan fitur canggih, pemeliharaan dan
pelatihan, dan dokumentasi dan buku tentang penggunaan software. Dengan demikian,
keuntungan dari software open source bukanlah biaya yang rendah, melainkan independensi
dari provider tunggal penyelenggara software yang mungkin memiliki prioritas untuk tidak
merubah apapun dan mungkin mengunci pengadopsi ke dalam layanan dan komponen add-
on dengan tidak melibatkan pihak ke-tiga. Harga paket yang lebih murah menjadikan
software open source menarik untuk dijadikan software pembelian.
Disamping itu, beberapa keuntungan open source menurut Hoffer et al (2011) adalah :
1. Kelayakan / perkembangan aplikasi tidak bergantung pada satu vendor, serta harga yang
ditawarkan cukup murah.
2. Kemampuan untuk memodifikasi kode source dan menambahkan fitur baru yang diinginkan;
kode baru akan dengan mudah diperiksa oleh pengguna software yang lain; kemampuan
untuk meninjau sumber kode asli dapat memungkinkan anda untuk memeriksa secara
keseluruhan sebelum menyebarkan.
3. Tidak menjadi tergantung terhadap satu vendor maupun kode hak-milik tertentu sehingga
dengan mudah dapat mengembangkan software sesuai kebutuhan.
4. Biaya akuisisi yang sama untuk sebuah copy atau ribuan copy sehingga dapat lebih murah
untuk memproduksi software dalam jumlah besar untuk digunakan dalam organisasi (global)
tanpa perlu memperoleh lisensi-multi pengguna sebagai hak milik.
5. Software dapat digunakan untuk tujuan apapun (misalnya distribusi software ke dalam
software yang dibuat sendiri untuk aktivitas profit-making)
6. Karena kode source terbuka, mungkin antarmuka software open source lebih mudah dengan
paket yang lain, dan layanan ini tidak harus bergantung pada vendor.

Terdapat beberapa risiko dalam aplikasi open source, antara lain :

1. Tidak ada kelengkapan dokumen tanpa membayar software pada beberapa provider
2. Hanya komoditas-tipe yang layak dalam aplikasi; jika tidak, tidak ada cukup dorongan untuk
mengembangkan aplikasi.
3. Kemungkinan dalam duplikasi usaha
4. Kehati-hatian dalam memiliki lisensi untuk software yang dibutuhkan

NEW PURCHASING OPTION: APPLICATION SERVICE PROVIDERS (ASPs)

Tren baru sehubungan dengan implementasi paket solusi dimulai dengan munculnya
dalam IT; Application service providers (ASPs). Dalam opsi pembelian ASP, pembeli
memilih untuk menggunakan aplikasi "host" daripada membeli aplikasi software dan
menggunakan host sendiri.
ASP merupakan provider layanan yang sedang ongoing dan Opsi ASP berbeda
dengan keputusan make-versus-buy decision. Alih-alih memilki perjanjian lisensi software
dengan perusahaan yang mengembangkan software, perusahaan membayar pihak ke tiga
(ASP) untuk memberikan fungsionalitas software melalui internet untuk karyawan
perusahaan dan kadang-kadang mitra bsinis perusahaan. Host ASP memiliki sendiri lisensi
untuk software. Hampir setiap software dapat dikirim melalui ASP, mulai dari otomatisasi
basic office hingga software aplikasi spesialisasi dan sistem ERP. Layanan ASP yang paling
sering diketahui adalah hosting websita, email, keuangan/akuntansi , dan e-commerce. Klien
ASP membayar sesuai dengan layanan servis yang mereka perlukan, daripada membeli
seharga minimun lisensi dari vendor yang asli.
Provider ASP mungkin adalah spesialis dalam host software tertentu, atau dalam
rangkaian software industri vertikal. Mayoritas vendor teknologi seperti Microsoft dan
Oracle, juga menyediakan berbagai variasi penyimpanan data dan software aplikasi lewat
opsi ASP. Banyak orientasi host ASP yang mendukung ukuran small-to-medium bisnis pada
area geografis tertentu. Beberapa ASPs membantu layanan seperti mengatur networking lokal
dan layanan ISP untuk menyediakan akses internet, dan pembelian dan dan memelihara
workstation thin-client untuk pelanggan mereka.
Mayoritas keuntungan menggunakan pakte pembelian, juga termasuk keuntungan
dalam memilih ASP adalah : 1. Penghematan Biaya dan 2. Kecepatan implementasi.
 Layanan berbasis langganan seperti ASP biasanya menggunakan layanan biaya bulanan
daripada membayar besar di awal untuk investasi IT di kedua paket software dan investasi
infrastruktur tambahan untuk menjadi host paket. Layanan dapat dihentikan setiap waktu
tanpa sunk cost yang besar terkait pembelian. Untuk perusahaan dengan karyawan yang
tersebar luas dan membutuhkan akses remote, ASP juga memberikan solusi untuk
mengurangi akses jaringan dan biaya pelayanan lainnya.
Karena paket ini juga khususnya sudah dijalankan dan running on dalam host
komputer ASP, implementasi proyek juga harus mengurangi waktu penggunaan. Juga,
layanan hosting menyediakan seluruh pemeliharaan software dan dukungan operasional,
membebaskan staff IT untuk bekerja pada aplikasi lain. Seringnya, organisasi mampu untuk
menggunakan paket dengan fungsionalitas yang lebih daripada mungkin kemampuan dengan
membeli software secara langsung.
Namun, ada juga beberapa kelemahan potensial, termasuk ketergantungan pada
vendor eksternal tidak hanya untuk paket perangkat lunak tetapi juga untuk operasi on going.
Proses yang baik untuk membuat keputusan pembelian yang terbaik dan kontrak untuk
tingkat layanan yang dibutuhkan bahkan lebih penting ketika membuat perjanjian ASP.
Sebuah proses pembelian yang hati-hati menilai kemampuan ASP untuk memberikan kinerja
yang handal, keamanan data organisasi, dan kemungkinan ASP bertahan di pasar yang sangat
penting bagi kontrak ASP, karena pasar ini masih dalam masa pertumbuhan. Beberapa risiko
tersebut tampaknya berkurang ketika host ASP juga software besar vendor seperti SAP atau
PeopleSoft untuk modul ERP atau Siebel Systems untuk modul CRM.
ASP bekerja dengan baik sebagai aplikasi yang berdiri sendiri. ASP tidak termasuk
dalam bisnis yang terintegrasi dengan software Klien. Juga, tuan rumah tidak akan
menyesuaikan perangkat lunak untuk klien (melampaui segala fitur kustomisasi yang
dibangun ke dalam software seperti termasuk logo organisasi Anda dalam dokumen yang
dihasilkan komputer). Keamanan (memastikan data Anda akan dilindungi dari akses oleh
orang lain, terutama apabila di organisasi pesaing menggunakan layanan hosting yang sama)
dapat menjadi perhatian, tetapi kebanyakan ASP menyediakan layanan keamanan high-end.
Akhirnya, layanan hosting mungkin mengharuskan Anda untuk mengkonversi ke versi baru
dari paket perangkat lunak, yang mungkin tidak bisa ketika Anda ingin mengkonversi.
Metrik kinerja vendor dan hukuman bagi yang melanggar harus menjadi bagian
penting dari kontrak. perjanjian tingkat layanan harus menjadi bagian dari kontrak, di mana
ekspektasi kinerja spesifik telah ditetapkan untuk variasi metrik operasional seperti sistem
uptime, waktu recovery, waktu tunggu panggila ke helpdesk, pemberitahuan tentang upgrade
software, dan faktor-faktor lain yang penting untuk cutomer.