Key People
- Kyle Baxter -> presiden Baxter Manufacturing
Company, Inc.
- Sue Barkley -> wakil presiden customer relation
- Nancy Shaw -> manager MIS pertama
- Lucas moore -> wakil presiden dari manufacturing
- Don Collins -> manajer MIS kedua
- Lou Wilcox -> controller
Sejarah
 Perusahaan dibentuk pada tahun 1978- Chairman
Walter R. Baxter
 Berlokasi di kota kecil Midwestern
 Bisnis manufacturing yang dikelola keluarga
 Karyawan 420 orang
 Pemanufaktur deep-drawn stampings-electric
motor housing
- Memproses dalam menciptakan part melalui
penggunaan cetakan khusus yang menekan
lembaran logam menjadi bentuk desain
tertentu
 Fasilitas Baxter merupakan salah satu yang
terbaik di negaranya
- 140,000 square feet facility
- 39 presses-each with feeds, reels, dan sistem
deteksi elektronik
- dengan kapasitas untuk mengelas, mengebor,
tap, dan memasang stamping ke bagian yang
lebih kompleks
 Konsumen: industri automobile (85%) dan
insdustri peralatan (15%)
- Ford
- General motors
- Honda of America
- General Electric
- Whirlpool (peralatan dapur dan laundry
- Maytag (peralatan rumah tangga, ex mesin
cuci, dll)
- Amana (peralatan rumah tangga, ex kulkas,
dll)
 Pada 1987 PC pertama diperkenalkan –
menggunakan Lotus spreadsheet
 Pada 1989 departemen MIS dibentuk – Nancy
Shaw
- Nancy Shaw (manajer MIS) memperkenalkan
sistem IS kepada perusahaan dimulai dengan:
1. Minicomputers
2. Interoffice e-mail
3. Financial program:
- Payroll
- Accounts payable/receivable
- General ledger
 Pada 1989 Baxter mulai menemui masalah
kapasitas yang terus bertumbuh
- Hasilnya, mereka membutuhkan paket
scheduling software
 Percobaan pertama:
- Nancy Shaw memilih vendor berdasarkan
risetnya
- Gagal karena:
1. Panduan yang error
2. Pelatihan yang buruk
3. Dukungan vendor yang tidak mencukupi
kebutuhan perusahaan
4. Vendor bangkrut
 1990-1991:
- Baxter menolak pesanan konsumen karena
terbatasnya kapasitas produksi
- Electronic Data Interchange (EDI) yang diadaptasi:
1. Karena pakai filosofi JIT
- Hanya “membawa/carry” minimal
inventories dari raw materials and parts
- memesan berdasarkan kebutuhan
2. Setelah konversi ke EDI—sistem pabrik tidak
komplit dan terfragmentasi
- Mereka harus mencetak dan mengunci
(ngelock atau rekey) tiap order
 Pada 1992 Baxter membuat investasi untuk
meningkatkan kapasitas
 Pada 1994 nancy Shaw meninggalkan BMC
 Don Collin menggantikan Nancy Shaw
- Dengan pengalaman kerja 20 tahun sebagai
analis sistem utama
 Percobaan kedua:
- Baxter memutuskan sistem sebagai grup
- Pelatihan lebih baik
 Masalah utama
- Panduan error
- Vendor tidak paham cara kerja BMC
- Prioritas penjadwalan
1. Akibat: reset seluruh sistem
2. Harus reenter semua pesanan (memakan
terlalu banyak waktu for staff
Analisis
 Agar Baxter maju maka mereka butuh
mengimplementasikan sistem yang
komprehensif:
- Isu: make or buy?
1. Manajemen bimbang
2. Duel pendapat: moore vs Collin
3. Computer usang
4. Budget: $200,000 untuk software dan
hardware
5. Membuat komite pengarah (steering
committee) untuk menyetujui proyek dan
menetapkan prioritas pengembangan sistem
- Kyle Baxter, Lou Wilcox, Sue Barkley &
Don Collins
Lucas Moore (VP of manufacturing): BUY
 Time Critical Manufacturing (TCM) software yang
diciptakan oleh Effective Management System
(EMS)
- Sistem sudah digunakan oleh banyak
pemanufaktur
+ untuk menginstal advanced system:
1. Durasi: 6 bulan
2. Cost: $220,000
+ untuk membangun sistem:
1. Durasi: 2 tahun
2. Cost: $400,000
 EMS:
- Memiliki keberadaan geografis dan konsultan
yang banyak
- lebih dari 13 tahun Berpengalaman dalam
menggunakan TCM
 Yang ditawarkan EMS:
1. Konsultasi dan manajemen implementasi
2. Pelatihan
3. upgrade pelayanan, desain modifikasi, dan
pemrograman
 TCM mencakup:
1. Model untuk perencanaan dan penambahan
2. Customer supply chain
3. Material supply chain
4. Manufacturing execution systems
5. Decision support dan enterprise tools

Don Collins (manajer MIS): MAKE
 EMS Software terlalu kompleks
- Karena terus mengubah proses manufaktur
 Cost buying: $440,000 vs Cost of making:
$420,000
- Durasi: 1 tahun (beli) dan 2 tahun (make)
 Sistem tidak sesuai dengan cara bisnis
perusahaan berjalan
- Apakah kita mengubah bagaimana kita
menjalankan bisnis?
 Trust issue sama vendor dalam melakukan
perubahan
Sue Barkley dan Kyle Baxter dilemma
 Alasan:
1. Pengalaman gagal 2x sebelumnya
2. Konsumen tetep happy
3. Sistem tidak efisien
4. Setiap divisi punya agenda masing2
Rekomendasi
 MIS steering committee harus mengevaluasi:
1. Core vs Context
- Core activities merupakan kunci diferensiasi
antara perusahaan satu dengan yang lain
- dalam hal aktivitas inti, sistem informasi
harus sesuai dengan aktivitas bisnis, bukan
sebaliknya
2. Coverage
Paket harus bertemu setidaknya 80% dari
fungsionalitasnya
3. Arah
Fleksible, mudah dijaga, dapat diperluas atau
dikembangkan
4. Total cost of ownership (TCO)-Includes:
Cost of acquisition, konfigurasi,
customization, ongoing support,
maintenance, evolusi aplikasi
5. Skala
Semakin besar skala semakin penting dimana
aplikasi merepresentasikan fungsi inti bisnis
6. timing
waktu implementasi paket harus
dipertimbangkan karena ketika
membandingkannya dengan membuat paket
terkustomisasi
 Baxter harus membeli sistem karena
1. perusahaan ingin berkembang dan butuh
aplikasi yang memiliki kapasitas untuk
menangani ekspansi tersebut
2. aplikasi yang dikembangkan secara internal
membutuhkan lebih banyak upaya untuk
dikembangkan
3. BMC bekerja dengan perusahaan besar,
untuk tetap kompetitif mereka harus
menjalankan bisnisnya dengan cara yang
lebih maju
4. Dipegang oleh orang yang berpengalaman
(moore) dan clientnya sudah ratusan
perusahaan
EMS adalah sistem yang sesuai karena:
1. Aplikasi sudah digunakan pada perusahaan lain
2. Panduan di aplikasi mencakup aktivitas produksi,
yaitu penerimaan order, produksi, scheduling,
dan shipping
3. EMS akan menyediakan pelatihan onsite dan
ongoing support
The make-or-buy decision
 Perusahaan besar seakrang cenderung pengembangan
kustom dan beli
 bisnis kecil cenderung beli
 soalnya kalo buat bakal dibikin sesuai dengan
kebutuhan perusahaan, sedangkan kalo beli
implementasinya lebih cepat dan cost saving
 keunggulan beli:
1. mengurangi waktu untuk mengimplementasikan
2. cost akuisisi keseluruhan itu lebih rendah
3. kualitas aplikasi tinggi (debugged (eliminasi error
atau masalah) dan prakteknya terbaik)
 kelemahan beli:
1. risiko karena kurangnya pengetahuan paket
2. risiko karena dibutuhkan perubahan pada sistem
organisasional
3. dari awal pemasangan hingga berjalannya sistem
bergantung sama vendor
 tahapan beli (pendekatan sdlc):
1. definition
- analisis kelayakan: menentukan apakah sistem
yang diusulkan layak secara ekonomi, teknis,
dan operasional. Diinvestigasi apakah sistem
paketnya layak, terus analisis cost-benefitnya
terinci dgn baik untuk penganggaran dan
pemantauan yg lebih baik dimasa depan
- definition requirement atau disebut juga analisis
sistem atau desain logis: spesifikasi terperinci
tentang apa yang harus dilakukan sistem dalam
input yang harus diterima, data yang harus
disimpan, proses yang harus dilakukan, output
yang harus dihasilkan, dan persyaratan kinerja
yang harus dipenuhi. Intinya fokus dalam
menentukan persyaratan yg dibutuhkan utk
mengembangkan request for proposal (RFP)
- membuat short list paket yang sesuai:
persyaratan organisasi digunakan untuk
menghilangkan kandidat dan menyisakan
kandidat terbaik yang diidentifikasi dalam
analisis kelayakan. Mengevaluasi fitur apa yang
tersedia di paket tsb, compatible ngga sama
hardware dan software perusahaan skrg, dan
track record vendor
- menentukan kriteria evaluasi: bisnis dan anggota
tim IS perlu bekerja sama untuk menentukan
kriteria yang relevan tentang kandidat paket
(kemampuan fungsionalnya, persyaratan
 teknisnya mudah apa ngga, dll) dan vendor
(dukungan yang ditawarkan apa sj) untuk memilih
yang terbaik.
- mengembangkan dan mendistribusikan Request
For Proposal (RFP): dokumen resmi yang dikirim
ke vendor potensial yang mengundang mereka
untuk mengirimkan proposal yang menjelaskan
paket perangkat lunak mereka dan bagaimana hal
itu akan memenuhi kebutuhan perusahaan. RFP
kasih informasi kepada vendor ttg tujuan dan
persyaratan sistem, lingkungan di mana sistem
akan digunakan, kriteria umum yang digunakan
untuk mengevaluasi proposal, kondisi dalam
submit proposal. For further content find (sample
rfp table of content)
- mengevaluasi respon vendor dan pilih paket:
mengevaluasi data dari respon vendor thdp rfp,
demonstrasi vendor terkait paket, referensi
pengguna dari perusahaan lain. Ini dievaluasi ttg
bagaimana bagusnya paket tersebut dalam
memenuhi kebutuhan perusahaan
negoisasi kontrak sebaiknya sama pengacara
perbedaan antara kebutuhan dan kemampuan paket
perlu ditangani dengan:
- memodifikasi paket
- mengubah prosedur internal
- beroperasi dengan perbedaan
2. konstruksi
- system design system building (untuk modifikasi
paket): biasanya vendor tidak memberikan kode
sumber untuk paket tersebut, sehingga
perusahaan biasanya mengontrak vendor (atau
perusahaan pihak ketiga bersertifikat) untuk
memodifikasi paket.
perubahan juga dapat request untuk sistem
perusahaan lain yang berinteraksi dengan paket
- system testing
percobaan penerimaan pengguna terhadap paket
yang terkonfigurasi/dimodifikasi
spesialis sistem informasi atau vendor mencoba
peralatan organisasi
3. implementasi
1. instalasi
- rencana instalasi, training, data cleanup, dan
konversi
- kesuksesan berd.: kualitas dukungan vendor,
ukuran paket dan kompleksitasnya
- perhatian spesial dibutuhkan pada proses
training, khususnya jika terdapat perubahan
signifikan terhadap cara karyawan
melakukan pekerjaannya
- manajemen perubahan merupakan paket
aktivitas yang didesain untuk membantu
pengguna bisnis dalam menghadapi
resistensi terhadap sistem yang baru
2. operasi
- pengoperasian sama, mau paket dibangun
atau dibeli
- kesuksesan awal bergantung besar terhadap
komunikasi yang baik dengan vendor
- kesuksesan jangka panjang bergantung pada
seberapa baik sistem terintegrasi dengan
operasi perusahaan yang sedang berjalan
3. maintenance
- paling sering= vendor menghandle
maintanacenya
- advantage: bisa memandu menghindari cost
yang siginifikan terhadap perubahan sistem
dimasa depan
- disadvantage: perushaan yg membeli secara
total bergantung pada vendor terhadap
perubahan sistem dimasa depan dan
mungkin tidak memberikan perubahan
spesifik terhadap keinginan perusahaan
CUSTOM
 
Pendekatan SDLC juga menyediakan baseline dari
pemahaman apa saja yang terlibat di dalam
pengembangan sebuah sistem aplikasi, baik oleh
tenaga profesional SIstem Informasi yang
dipekerjakan organisasi atau oleh tenaga profesional
SI yg dipekerjakan perusahaan pengembang software,
ataupun kombinasi keduanya.
Dorongan keseluruhan dari 3 fase SDLC cukuplah jelas.
Pada fase definition (feasibility analysis, requirements
definition) sangatlah penting: fase ini menentukan cara
kerja pengembangan sistem dan mendefinisikan secara
presisi apa yang harus sistem kerjakan dalam detail yang
cukup untuk spesialis SI untuk membangun sistem yang
benar. pada fase construction (system design, building,
testing), para spesialis SI memproduksi sebuah sistem
kerja berdasarkan seperangkat spesifikasi yang
ditunjukkan pada fase sebelumnya, hal ini termasuk
teknik yang terstruktur seperti: data flow diagram, E-R
models, dan structure chart. Pada fase implemenrarion
(installation,, operations, maintenance), sebuah sistem
baru diinstal menjadi operasional di dalam organisasi dan
sistem ini harus dimantain atau di modified seperti yang
dibutuhkan sehingga sistem ini tetap melanjutkan
merefleksikan kebuthan perubahan dari sebuah
organisasi. 2 langkah terakhir tersebut )operasi dan
maintenance( sydag termasuk dalam life-cycle sebagai
cara untuk mengakui secara formal apa yang dibuat
sesuai pesanan sebagai modal investasi perusahaan yang
selanjutnya menimbulkan biaya operasional dan
maintenance.
the make-or-buy decision bukan praktik terbaik saat ini. Kelemahan ini saja berarti
bahwa organisasi harus memiliki proses yang sangat
- Pilihan antara membangun aplikasi khusus dan membeli baik yang akan membantu mereka membuat keputusan
(atau menyewa) paket perangkat lunak — keputusan pertukaran terbaik tentang fitur dan kemampuan
make-orbuy — harus dibuat bersama oleh manajer perangkat lunak untuk organisasi. Seperti yang
bisnis yang membutuhkan perangkat lunak dan dijelaskan selanjutnya, ini membutuhkan metodologi
profesional IS yang memiliki pengetahuan untuk menilai yang akan memperhitungkan pengetahuan tentang
manfaat dan risiko teknis . kemampuan paket serta pertimbangan bisnis dan
- Untuk organisasi dengan personel IS yang terampil, tiga teknis yang diinformasikan tentang seberapa baik
keuntungan paling jelas dari perangkat lunak yang paket akan memenuhi kebutuhan organisasi.
dikemas adalah (1) penghematan biaya, (2) kecepatan - Masalah lain yang berperan dalam pengambilan
implementasi perangkat lunak berkualitas yang lebih keputusan makeor-buy adalah kelayakan finansial dari
cepat, dan (3) staf internal tersedia untuk mengerjakan vendor utama atau yang diinginkan, apakah perangkat
aplikasi lain yang tidak dibeli. lunak tersebut sesuai dengan perangkat lunak sistem
- Paket perangkat lunak (beli) biasanya lebih murah yang dipilih organisasi, apakah vendor tersebut
daripada solusi khusus karena vendor perangkat lunak memiliki visi untuk peningkatan paket itu. kompatibel
akan menjual paket tersebut ke banyak organisasi. dengan kebutuhan organisasi Anda di masa depan
Artinya, perusahaan yang memperoleh perangkat lunak (tidak hanya saat ini), keandalan vendor dalam
akan berbagi biaya pengembangan dan peningkatan memberikan rilis baru tepat waktu, dan total biaya
paket. kepemilikan (yaitu, tidak hanya mempertimbangkan
- Beberapa biaya tambahan untuk kustomisasi oleh staf biaya pembelian tetapi juga biaya jangka panjang
atau konsultan internal biasanya diperlukan (misalnya, untuk memelihara dan memutakhirkan perangkat
untuk membuat judul laporan menjadi lokal, untuk lunak — faktor yang sangat penting untuk
menggunakan nama data spesifik perusahaan). dipertimbangkan dengan paket sumber terbuka, yang
- Paket perangkat lunak juga biasanya dapat akan kita bahas nanti di bab ini).
diimplementasikan lebih cepat daripada aplikasi kustom
karena sudah ada; dalam lingkungan bisnis yang Di akhir bab ini kami juga membahas secara singkat opsi
berubah cepat saat ini, ini bisa menjadi keuntungan pengadaan yang mencakup kontrak dengan vendor untuk
yang sangat penting. Ini bisa menjadi penting ketika staf "menjadi tuan rumah" (menjalankan) satu atau lebih
TI dan bisnis kurang berpengalaman dengan aplikasi, aplikasi (misalnya, Salesforce.com) untuk perusahaan
sehingga membuat proyek pengembangan sangat bisnis di bawah kontrak sewa (lihat bagian dari bab ini
berisiko. Sebuah paket mungkin lebih disukai untuk berjudul "Opsi Pembelian Baru: Penyedia Layanan
mendukung fungsi bisnis inti dan umum yang tidak Aplikasi"). Proses untuk memutuskan penyedia layanan
bersaing dengan organisasi Anda dengan organisasi lain aplikasi mirip dengan proses untuk memutuskan paket
yang juga dapat memperoleh teknologi yang sama. perangkat lunak yang dibeli, dengan beberapa
Tentu saja, keuntungan nyata datang dari penggunaan pertimbangan khusus karena sambungan jarak jauh ke
paket secara cerdas dengan cara yang tidak dapat data dan perangkat lunak.
dilakukan pesaing. Staf internal kemudian dapat
mencurahkan waktunya untuk membuat semua aplikasi
dapat beroperasi dan mengembangkan aplikasi yang
membutuhkan pengetahuan lokal atau memiliki
keunggulan kompetitif.
- Namun, ada juga beberapa kerugiannya. Satu
kelemahan utama dari membeli solusi aplikasi adalah
perangkat lunak yang dikemas jarang benar-benar
sesuai dengan kebutuhan perusahaan. Untuk
organisasi yang memperoleh paket untuk menggantikan
sistem lama yang dikembangkan khusus, jenis
perubahan ini dapat memiliki beberapa konsekuensi
penting bagi bisnis. Umumnya, ini berarti bahwa
pengguna bisnis mungkin diminta untuk "melepaskan"
fitur perangkat lunak kustom lama yang tidak
didukung paket.
- Paket mungkin dapat disesuaikan untuk menambahkan
fitur khusus, tetapi penyesuaian dapat membuat
peningkatan paket jauh lebih sulit saat rilis baru terjadi
dan mungkin dibatasi oleh lisensi perangkat lunak yang
memungkinkan paket tersebut didukung oleh vendor.
- Pilihan lain adalah bagi organisasi untuk mengubah
prosesnya agar sesuai dengan yang didukung oleh
perangkat lunak. Ini mungkin diinginkan, meskipun
menyakitkan, jika proses organisasi tidak efisien atau