Project integration management
Sembilan
proses project integration management dapat menjelaskan bidang ilmu dan
berbagai pengalaman praktis di manajemen proyek, dari sudut pandang
komponen-komponen prosesnya. Proses-proses tersebut diorganisasikan menjadi
sembilan bidang ilmu yang akan dijelaskan dibawah ini:
• Manajemen Lingkup Proyek, menjelaskan proses-proses yang dibutuhkan, agar
dapat
dipastikan bahwa proyek telah mencakup seluruh pekerjaan yang benar-benar
dibutuhkan, agar proyek berhasil diselesaikan. Terdiri dari persiapan,
perencanaan
lingkup, penetapan lingkup, verifikasi dan pengendalian perubahan lingkup.
• Manajemen Waktu Proyek, menjelaskan proses-proses yang dibutuhkan agar dapat
dipastikan proyek selesai tepat waktu. Terdiri dari penetapan aktifitas,
pengurutan aktifitas, perkiraan lama aktifitas, serta penyusunan dan
pengendalian
jadwal.
• Manajemen Biaya Proyek, menjelaskan proses-proses yang dibutuhkan agar dapat
dipastikan proyek selesai, sesuai dengan anggaran yang disetujui. Terdiri dari
perencanaan sumber daya, perkiraan biaya, anggaran biaya dan pengendalian
biaya.
• Manajemen Sumber Daya Manusia Proyek, menjelaskan proses-proses yang
dibutuhkan
untuk menggunakan sumber daya manusia yang terlibat dalam proyek, secara paling
efektif. Terdiri dari perencanaan organisasi, perekrutan staff dan pembangunan
tim
kerja.
• Manajemen Komunikasi Proyek, menjelaskan proses-proses yang dibutuhkan untuk
dapat
dipastikan agar informasi proyek dapat dikumpulkan, disusun, disebar, dan
disimpan. Terdiri dari perencanaan komunikasi, distribusi informasi, pelaporan
kinerja, dan penyelesaian administratif.
• Manajemen Resiko Proyek, menjelaskan proses-proses yang berhubungan dengan
pengidentifikasian resiko, kuantifikasi resiko, penyusunan penanggulangan
resiko
dan pengendalian penanggulangan resiko.
• Manajemen Pengadaan Proyek, menjelaskan proses-proses yang dibutuhkan untuk
menghasilkan barang atau jasa dari pihak lain. Terdiri dari perencanaan
pengadaan,
perencanaan tata cara undangan ke peserta, rapat undangan peserta, pemilihan
peserta, pemilihan mitra, pelaporan serta administrasi kontrak kerja dan
penyelesaian kontrak.
• Manajemen Integrasi Proyek, menjelaskan berbagai proses yang dibutuhkan, agar
dapat dipastikan, berbagai elemen dari proyek dikoordinasikan dengan baik.
Manajemen integrasi terdiri dari pembuatan rencana proyek, pelaksanaan rencana
proyek dan pengendalian perubahaan secara keseluruhan.
Project Scope Management
Pengertian
Project Scope Management
- Scope
mengacu pada semua pekerjaan yang terlibat didalam menciptakan
produk-produk dari proyek dan proses yang digunakan untuk membuatnya.
- Delivarable
adalah produk yang diproduksi sebagai bagian dari proyek seperti perangkat
keras, dokumen perencanaan, atau rapat.
- Project
Scope Management mencakup proses-proses yang terlibat dalam mendefinisikan
dan mengendalikan apa yang tidak termasuk kedalam proyek.
Proses
Projeck Scope Management
- Scope
planning : menentukan bagai mana ruang lingkup akan ditentukan,
diperifikasi, dan dikendalikan.
- Scope
definition: menelaah project charter dan pernyataan ruang lingkup awal dan
menambahkan informasi lebih lanjut sebagai persyaratan yang dikembangkan
dan perubahan permintaan tersebut disetujui.
- Membuat
WBS:mengelompokkan penyampaian proyek besar menjadi lebih kecil, komponen
lebih mudah ditangani.
- Scope
verivikasi : penerimaan mempormalkan ruang lingkup proyek.
- Scope
Control : Pengendalian perubahan ruang lingkup proyek.
Inisialisasi
Proyek : Rencana strategis dan pemilihan proyek
- Perencanaan
strategis meliputi penentuan tujuan jangka panjang , memprediksi tren masa
depan, dan proyeksi kebutuhan produk dan layanan baru.
- Organisasi
sering melakukan analisis SWOT.
- Identifikasi
proyek potensial.
- Gunakan
metode realistis untuk memilih proyek yang sedang dikerjakan.
- Merumuskan
inialisasi proyek dengan mengeluarkan project charter.
Mengapa
perusahaan investasi pada IT
- Hal ini
sering sulit untuk memberikan justifikasi yang kuat untuk berbagai proyek
IT. Tetapi semua orang setuju mereka memiliki nilai tinggi
- Lebih
baik menghitung mas karat dari pada menghitung sen dengan tepat.
- Kriteria
yang penting untuk proyek yaitu : ada kebutuhan untuk proyek tersebut
seperti dana yang tersedia cukup dan dana yang kuat akan membuat proyek
tersebut berhasil.
Identifikasi
proyek potensial
- Banyak
organisasi mengikuti proses perencanaan untuk memilih proyek IT.
- Sangat
penting untuk menyelaraskan proyek IT dengan strategi bisnis.
- Penelitian
menunjukan bahwa mendukung tujuan bisnis eksplisit adalah nomor satu alas
an dikutip untuk berfantasi dalam proyek IT
Metode
pemilihan proyek
- Biasanya
tidak cukup waktu atau sumber daya untuk menerapkan semua proyek.
- Metode
untuk proyek-proyek memilih meliputi :
- Berfokus
pada kebutuhan organisasi yang luas
- Kategorikan proyek tegnologi informasi
- Tunjukkan net present value atau analisis keuangan lainnya
- Menggunakan metode skor tertimbang
- Menerapkan balanced sorecard
Kategori proyek IT
- Suatu
kategorisasi menilai apakah proyek tersebut memberikan respon terhadap
suatu masalah, kesempatan.
- Kategorisasi
lain adalah berdasarkan waktu yang diperlukan untuk menyelesaikan sebuah
proyek atau tanggal dengan yang harus dilakukan.
- Kategirisasi
lain adalah prioritas keseluruhan proyek
PROJECT TIME MANAGEMENT
Mengatur waktu dalam penyelesaian project, termasuk di
dalamnya waktu-waktu yang akan hilang dalam pengerjaan project.
mendefinisikan aktifitas project kedalam jadwal
pengerjaan project. Berdasarkan kebutuhan di setiap fase projectnya .jadi dalam
proses ini kita harus lebih mendetailkan lagi aktifitas-aktifitas apa yang di
butuhkan dalam perancangan pengerjaan project . terdapat beberapa fase tahapan
pembagian tugas, nah di setiap fase itulah yang harus di perjelas tentang
apa saja aktifitas yang harus di lakukan, agar dalam aktifitas pengerjaan
proyek ini berjalan dengan efisien .
Menyusun urutan aktivitas pekerjaan dan
mendokumentasikannya.Setiap aktifitas harus di menaj sebaik mungkin, dan jangan
lupa mendokumentasikannya karena dokumentasi sangat penting dalam pembuatan
sebuah project
- Activity
resource estaming
Menghitung setiap tipe sumber daya yang
dibutuhkan.Jadi kita harus dapat menganalisis sumber daya apa yang di butuhkan
untuk membangaun project agar sesuai dengan yang di inginkan
- activity
duration estaming
menghitung waktu yang diperlukan untuk mentelesaikan
setiap pekerjaan project yang harus di selesaikan setiap waktu. Harus di
lakukan agar supaya waktu pengerjaan sesuai dengan perjanjian waktu project
menganalisis urutan aktuvitas, waktu,kebutuhan sumber
saya dengan jadwal pekerjaan project yang dudah di tetapkan.
mengontrol setiap pengubah jadwal project. Harus
bertindak cepat dengan menyesuaikan jadwal-jadwal lainya agar tidak terjadi
lost time.
Project
Quality Management
Manajemen Mutu
Proyek adalah salah satu proses yang paling penting dalam Siklus Hidup untuk
menentukan proyek ini di trek. Pengujian dilakukan selama proses mutu harus
peta secara langsung ke persyaratan. Jika tidak, proses tersebut perlu dikaji
ulang. Kualitas proses mencakup semua kegiatan organisasi melakukan yang
menentukan kebijakan kualitas, tujuan, dan tanggung jawab sehingga proyek akan
memenuhi kebutuhan yang dilakukan. It menerapkan sistem manajemen mutu melalui
kebijakan, prosedur, dan proses perencanaan mutu, jaminan mutu, dan kontrol
kualitas, dengan kegiatan perbaikan proses yang berkesinambungan yang dilakukan
sepanjang, yang sesuai. Manajemen Mutu sering dikelola manajer lain dan
perawatan harus diambil untuk memastikan proyek Anda memiliki sumber daya
rekayasa kualitas yang diperlukan untuk melakukan pekerjaan itu. Itulah salah
satu alasan saya harus sangat ketat tentang membuat hubungan baik dengan semua
orang dalam tim proyek. Ini berlaku ganda ketika sumber daya Anda berada dalam
organisasi matriks dan tidak melapor kepada Anda.
Kualitas
Perencanaan: mengidentifikasi standar kualitas yang relevan dengan proyek dan
menentukan bagaimana untuk memuaskan mereka.
Lakukan Jaminan
Kualitas: menerapkan, kegiatan yang direncanakan kualitas sistematis untuk
memastikan bahwa proyek tersebut mempekerjakan semua proses yang diperlukan
untuk memenuhi persyaratan.
Lakukan Quality
Control: hasil pemantauan proyek tertentu untuk menentukan apakah mereka sesuai
dengan standar mutu yang relevan dan mengidentifikasi cara untuk menghilangkan
penyebab kinerja tidak memuaskan.
Proses ini
berinteraksi satu sama lain dan dengan proses di Wilayah Pengetahuan lain juga.
Setiap proses dapat melibatkan usaha dari satu atau lebih orang atau kelompok
orang berdasarkan kebutuhan proyek. Setiap proses terjadi setidaknya sekali
dalam setiap proyek dan terjadi pada satu atau lebih fase proyek, jika proyek ini
dibagi menjadi fase. Meskipun proses yang disajikan di sini sebagai elemen
diskrit dengan baik-didefinisikan antarmuka, dalam praktiknya mereka mungkin
tumpang tindih dan berinteraksi dengan cara yang tidak rinci di sini.
Pendekatan dasar
untuk manajemen mutu diuraikan dalam bagian ini dimaksudkan agar kompatibel
dengan Organisasi Internasional untuk Standardisasi (ISO). Pendekatan umum juga
harus kompatibel dengan pendekatan proprietary untuk manajemen mutu seperti
yang direkomendasikan oleh Deming, Juran, Crosby dan orang lain, dan pendekatan
non-eksklusif seperti Total Quality Management (TQM), Six Sigma, Mode Kegagalan
dan Analisis Efek, Desain review, Suara Pelanggan, Biaya Kualitas (coq), dan
Continuous Improvement.
Proyek Manajemen
Mutu harus mengatasi manajemen proyek dan produk dari proyek. Sementara Proyek
Manajemen Mutu berlaku untuk semua proyek, terlepas dari sifat produk mereka,
tindakan kualitas produk dan teknik yang khusus untuk jenis tertentu dari
produk yang dihasilkan oleh proyek tersebut.
Sebagai contoh,
kualitas produk perangkat lunak manajemen memerlukan pendekatan yang berbeda
dan ukuran dari pembangkit listrik tenaga nuklir, sedangkan pendekatan Kualitas
Manajemen Proyek berlaku untuk keduanya. Dalam kedua kasus, kegagalan untuk
memenuhi persyaratan kualitas dalam dimensi dapat memiliki konsekuensi negatif
yang serius untuk setiap atau semua dari stakeholder proyek. Sebagai contoh:
• Memenuhi
persyaratan pelanggan dengan lembur tim proyek dapat menghasilkan konsekuensi
negatif dalam bentuk gesekan karyawan meningkat, kesalahan tidak berdasar, atau
ulang
• Rapat tujuan proyek dengan terburu-buru jadwal pemeriksaan kualitas yang
direncanakan dapat menghasilkan konsekuensi negatif ketika kesalahan tidak
terdeteksi.
Kualitas adalah “sejauh mana seperangkat karakteristik yang melekat memenuhi
persyaratan”. Kebutuhan yang dinyatakan dan tersirat adalah masukan untuk
persyaratan proyek berkembang. Elemen penting dari manajemen mutu dalam konteks
proyek adalah untuk mengubah kebutuhan stakeholder, keinginan, dan harapan ke
dalam persyaratan melalui Analisis Stakeholder, yang dilakukan selama Lingkup
Manajemen Proyek.
Kualitas dan kelas
tidak sama. Grade kategori ditugaskan untuk produk atau jasa yang memiliki
penggunaan fungsional yang sama tapi karakteristik teknis yang berbeda.
Rendahnya kualitas selalu menjadi masalah; kelas rendah mungkin tidak. Sebagai
contoh, sebuah produk perangkat lunak dapat kualitas yang tinggi (tidak ada
cacat jelas, petunjuk dibaca) dan kelas rendah (sejumlah fitur yang terbatas),
atau berkualitas rendah (banyak cacat, dokumentasi pengguna kurang
terorganisir) dan kelas tinggi (banyak fitur) . Manajer proyek dan tim
manajemen proyek bertanggung jawab untuk menentukan dan memberikan tingkat yang
diperlukan, baik kualitas dan kelas.
Presisi dan
akurasi yang tidak setara. Presisi adalah konsistensi bahwa nilai pengukuran
berulang terkumpul dan telah menyebar sedikit. Akurasi adalah benar bahwa nilai
diukur sangat dekat dengan nilai sebenarnya. Pengukuran yang tepat tidak selalu
akurat. Sebuah pengukuran yang sangat akurat tidak selalu tepat. Tim manajemen
proyek harus menentukan berapa banyak akurasi / presisi atau keduanya
diperlukan.
Kepuasan
pelanggan: Memahami, mengevaluasi, mendefinisikan, dan mengelola ekspektasi
pelanggan sehingga persyaratan terpenuhi. Hal ini memerlukan kombinasi dari
kesesuaian dengan persyaratan (proyek harus menghasilkan apa kata itu akan
menghasilkan) dan kesesuaian untuk digunakan (produk atau jasa harus memenuhi
kebutuhan riil).
• Pencegahan lebih dari inspeksi: Biaya mencegah kesalahan umumnya jauh lebih
sedikit daripada biaya mengoreksi mereka, seperti diungkapkan oleh inspeksi.
Dikatakan bahwa biaya bug meningkat secara eksponensial sebagai proyek mencapai
penyelesaian. Pikirkan berapa banyak lagi masalah biaya jika mencapai lapangan
dan rilis baru harus diproduksi untuk memperbaikinya. Hal ini tidak hanya biaya
dalam dolar jelas, tetapi juga dalam reputasi perusahaan memberikan produk,
terutama di toko-toko yang berjalan 24 * 7.
• Tanggung jawab Manajemen: Kesuksesan membutuhkan partisipasi dari semua
anggota tim, tapi tetap tanggung jawab manajemen untuk menyediakan sumber daya
yang dibutuhkan untuk berhasil.
• Terus ditingkatkan: Rencana-do-check-tindakan siklus adalah dasar untuk
peningkatan kualitas (seperti yang didefinisikan oleh Shewhart dan dimodifikasi
oleh Deming, di Buku Pegangan ASQ, halaman 13-14, American Society for Quality,
1999). Selain itu, inisiatif peningkatan kualitas yang dilakukan oleh
organisasi yang melakukan, seperti TQM dan Six Sigma, dapat meningkatkan
kualitas manajemen proyek serta kualitas produk proyek. Proses perbaikan
meliputi model Malcolm Baldrige, CMM ®, dan CMMISM.
Biaya kualitas mengacu pada total biaya dari semua upaya yang berhubungan
dengan kualitas.
Keputusan proyek dapat mempengaruhi biaya operasional kualitas sebagai akibat
dari pengembalian produk, klaim garansi, dan kampanye ingat. Namun, sifat
sementara dari proyek berarti bahwa investasi dalam peningkatan kualitas
produk, terutama pencegahan cacat dan penilaian, sering dapat ditanggung oleh
organisasi memperoleh, bukan proyek, karena proyek tidak dapat bertahan cukup
lama untuk menuai hasilnya.
Analisis Biaya-Manfaat: Kualitas perencanaan harus mempertimbangkan
biaya-manfaat timbal balik. Manfaat utama dari memenuhi persyaratan kualitas
pengerjaan ulang kurang, yang berarti produktivitas yang lebih tinggi, biaya
rendah, dan kepuasan pemangku kepentingan meningkat. Biaya utama dari memenuhi
persyaratan kualitas adalah biaya yang terkait dengan kegiatan Manajemen
Kualitas Proyek.
Pembandingan:
Pembandingan melibatkan membandingkan praktek proyek yang sebenarnya atau
direncanakan untuk orang-orang dari proyek-proyek lain untuk menghasilkan
ide-ide untuk perbaikan dan untuk memberikan dasar yang digunakan untuk
mengukur kinerja. Proyek-proyek lain dapat melakukan dalam organisasi atau di
luar itu, dan dapat dalam yang sama atau di daerah lain aplikasi.
Desain Eksperimen:
Desain eksperimen (DOE) adalah metode statistik yang membantu mengidentifikasi
faktor-faktor yang dapat mempengaruhi variabel tertentu dari suatu produk atau
proses dalam pengembangan atau produksi. Ini juga memainkan peran dalam
optimasi produk atau proses. Pikirkan metode ilmiah.
Contohnya adalah di mana organisasi dapat menggunakan DOE untuk mengurangi
sensitivitas kinerja produk untuk sumber-sumber variasi yang disebabkan oleh
perbedaan lingkungan atau manufaktur. Aspek yang paling penting dari teknik ini
adalah bahwa ia menyediakan kerangka kerja statistik untuk secara sistematis
mengubah semua faktor penting, bukannya mengubah salah satu faktor pada suatu
waktu. Analisis data eksperimen harus menyediakan kondisi yang optimal untuk
produk atau proses, menyoroti faktor-faktor yang mempengaruhi hasil, dan
mengungkapkan adanya interaksi dan synergisms antara faktor. Sebagai contoh,
desainer otomotif menggunakan teknik ini untuk menentukan kombinasi dari
suspensi dan ban akan menghasilkan hasil yang paling diinginkan dalam waktu
tertentu.
Biaya Kualitas (coq):
Biaya kualitas adalah biaya total yang dikeluarkan oleh investasi dalam
mencegah ketidaksesuaian dengan persyaratan, menilai produk atau layanan untuk
kesesuaian dengan persyaratan, dan gagal untuk memenuhi persyaratan (ulang).
Biaya Kegagalan sering dikategorikan menjadi internal dan eksternal. Biaya
kegagalan juga disebut biaya kualitas yang buruk.
Perencanaan Kualitas Peralatan tambahan
Alat perencanaan kualitas lainnya juga sering digunakan untuk membantu
mendefinisikan situasi yang lebih baik dan membantu merencanakan kegiatan manajemen
mutu yang efektif. Ini termasuk diagram afinitas brainstorming,, analisis medan
kekuatan, teknik kelompok nominal, diagram matriks, flowchart, dan matriks
prioritas.
Project Procurement Management (Manajemen Pengadaan)
Pengertian dan pentingnya Project Procurement
Management.
Sampai saat ini, pengadaan ini merupakan
komponen, perlu, tetapi jarang dirayakan perusahaan multinasional. Tapi zaman telah berubah: ini hari, pengadaan organisasi
dalam perusahaan memainkan peran penting dalam keberhasilan perusahaan global
dengan cara yang kuno manajer pembelian tak pernah membayangkan. Dalam laporan podcast khusus, fakultas Wharton dan ahli
pengadaan di The Boston Consulting Group membahas mengapa fungsi pengadaan
telah meningkat menjadi menonjol seperti dalam lingkungan global yang sangat
kompetitif, dan bagaimana, sebagai pasokan komoditas kritis dan memperketat
kenaikan harga, perusahaan dapat menyusun strategi untuk mengurangi ini dan
risiko lainnya.
Proses Project Procurement Management.
Ini Manajemen
Pengadaan proses akan membantu Anda untuk membeli barang dan jasa dari
pemasok eksternal.Ini memberi Anda proses pengadaan lengkap
danprosedur pengadaan, yang menjelaskan langkah-demi-langkah, bagaimana
untuk membeli dari pemasok.Anda akan belajar bagaimana untuk mengeluarkan Purchase
Order, menerima dan menyetujui pengiriman, mendukung pembayaran pemasok dan
mengelola pemasok terhadap kontrak mereka.
Proses
pengadaan juga akan membantu Anda untuk:
· Identifikasi barang dan
jasa untuk mendapatkan
· Lengkapi Pembelian Pesanan
dan masalah kepada pemasok
· Menyepakati kerangka waktu
pengiriman dan metode
· Menerima barang dan jasa
dari pemasok
· Review dan menerima
barang-barang dibeli
· Menyetujui pembayaran
pemasok
Proses
Manajemen Pengadaan ini akan memungkinkan Anda untuk:
· Identifikasi tonggak
kontrak pemasok
· Tinjauan kinerja pemasok
terhadap kontrak
· Mengidentifikasi dan
memecahkan masalah kinerja pemasok
· Komunikasikan status untuk
manajemen
Pengadaan barang dan jasa
dari pemasok eksternal dapat menjadi jalan penting untuk banyak
proyek. Seringkali, kinerja pemasok akan merefleksikan kinerja tim proyek
secara keseluruhan. Ini karena itu penting bahwa Anda mengelola kinerja
pemasok Anda dengan hati-hati, untuk memastikan bahwa mereka menghasilkan
kiriman yang memenuhi harapan Anda.
Proses Manajemen Pengadaan
ini akan membantu Anda melakukan ini untuk mendapatkan hasil maksimal dari
hubungan eksternal Anda pemasok.
Rencana Procurement,
alat dan teknik.
Ada berbagai macam alat
perencanaan strategis yang tersedia - dalam pendekatan dasarnya mental dan
prosedur untuk menerapkan untuk mengembangkan rencana strategis yang efektif.Kami sudah
menjelaskan beberapa istilah dalam dan bagian definisi dari perencanaan ini
pengetahuan strategis, sehingga beberapa dari mereka akan menjadi duplcated
sini.
Perlu diketahui bahwa
banyak alat-alat perencanaan strategis tumpang tindih, jadi jika Anda sedang
mengatur proses perencanaan strategis Anda, jangan merasa Anda perlu
menggunakan semua dari mereka, atau bahkan banyak dari mereka. Gunakan alat
perencanaan strategis yang tampaknya masuk akal bagi Anda, DAN, alat yang Anda
merasa Anda benar-benar mengerti.
Penyelesaian kontrak.
Definisi
Metode Kontrak Selesai ¶
Metode
kontrak selesai juga dikenal sebagai metode penyelesaian kontrak adalah bentuk
pengakuan pendapatan yang digunakan untuk akuntansi berbasis proyek seperti
konstruksi. Metode kontrak selesai dari catatan akuntansi pendapatan yang
diperoleh pada semua proyek dalam periode ketika proyek selesai.
Project Risk Management
Pengertian
Manajemen
Dalam mengartikan dan mendefinisikan manajemen ada berbagai ragam, ada yang
mengartikan dengan ketatalaksanaan, manajemen, manajemen pengurusan dan lain
se- bagainya. Bila dilihat dari literatur-literatur yang ada, pengertian
manajemen dapat dilihat dari tiga pengertian:
1. manajemen
sebagai suatu proses.
2. manajemen sebagai suatu kolektivitas manusia
3. manajemen sebagai ilmu (science) dan sebagai seni (art).
Manajemen
sebagai suatu proses, melihat bagai mana cara orang untuk mencapai suatu tujuan
yang telah ditetapkan terlebih dahulu. Pengertian manajemen sebagai suatu
proses dapat dilihat dari pengertian menurut :
1. Encylopedia of The Social Science, yaitu suatu proses dimana pelaksanaan
suatu tujuan tertentu dilaksanakan dan diawasi.
2. Haiman, manajemen yaitu fungsi untuk mencapai suatu tujuan melalui kegiatan
orang lain, mengawasi usaha-usaha yang dilakukan individu untuk mencapai
tujuan.
3. Georçv R. Terry, yaitu cara pencapaian tujuan yang telah ditentukan terlebih
dahulu dengan melalui kegiatan orang lain.
Manajemen
suatu kolektivitas yaitu merupakan suatu kumpulan dari orang-orang yang bekerja
sama untuk mencapai suatu tujuan bersama. Kolektivitas atau kumpulan
orang-orang inilah yang disebut dengan manajemen, sedang orang yang bertanggung
jawab terhadap terlaksananya suatu tujuan atau berjalannya aktivitas manajemen
disebut manajer.
Manajemen sebagai suatu ilmu dan seni, melihat bagaimana aktivitas manajemen
dihubungkan dengan prinsip-prinsip dari manajemen. Pengertian manajemen sebagai
suatu ilmu dan seni dari :
1. Chaster I Bernard dalam bukunya yang berjudul JTAe^Bnctíon of the Executive,
bahwa manajemen yaitu seni dan ilmu, juga Henry Fajol, Alfin Brown Harold,
Koontz Cyril O’donnel dan GerQge K Terry.
2. Marry Parker FoUett menyatakan bahwa manajemen sebagai seni dalam
menyelesaikan pekerjaan melalui orang lain.
Dari
devinisi di atas dapat ditarik kesimpulan bahwa manajemen yaitu koordinasi
semua sumber daya melalui proses perencanaan, pengorganisasian, penetapan
tenaga kerja, pengarahan dan pengawasan untuk mencapai tujuan yang telah
ditetapkan terlebih dahulu
Manajemen
Risiko
Manajemen
risiko adalah suatu pendekatan terstruktur/metodologi dalam mengelola
ketidakpastian yang berkaitan dengan ancaman; suatu rangkaian aktivitas manusia
termasuk: Penilaian risiko, pengembangan strategi untuk mengelolanya dan
mitigasi risiko dengan menggunakan pemberdayaan/pengelolaan sumberdaya.
Strategi yang dapat diambil antara lain adalah memindahkan risiko kepada pihak
lain, menghindari risiko, mengurangi efek negatif risiko, dan menampung
sebagian atau semua konsekuensi risiko tertentu. Manajemen risiko tradisional
terfokus pada risiko-risiko yang timbul oleh penyebab fisik atau legal (seperti
bencana alam atau kebakaran, kematian, serta tuntutan hukum. Manajemen risiko
keuangan, di sisi lain, terfokus pada risiko yang dapat dikelola dengan
menggunakan instrumen-instrumen keuangan.
Sasaran dari pelaksanaan manajemen risiko adalah untuk mengurangi risiko yang
berbeda-beda yang berkaitan dengan bidang yang telah dipilih pada tingkat yang
dapat diterima oleh masyarakat. Hal ini dapat berupa berbagai jenis ancaman
yang disebabkan oleh lingkungan, teknologi, manusia, organisasi dan politik. Di
sisi lain pelaksanaan manajemen risiko melibatkan segala cara yang tersedia
bagi manusia, khususnya, bagi entitas manajemen risiko (manusia, staff, dan
organisasi).
Kegiatan
proyek biasanya dilakukan untuk berbagai bidang antara lain sebagai berikut:
* Perbaikan
fasilitas yang sudah ada. Merupakan kelanjutan dan usaha yang sudah ada
sebelumnya. Artinya sudah ada kegiatan sebelumnya, namun perlu dilakukan
tambahan atau perbaikan yang diinginkan
* Pembangunan fasilitas baru. Artinya merupakan kegiatan yang benar-benar baru
dan belum pernah ada sebelumnya, sehingga ada penambahan usaha baru..
* Penelitian dan pengembangan. Merupakan kegiatan penelitian yang dilakukan untuk
suatu fenomena yang muncul di masyarakat, lalu dikembangkan sedemikian rupa
sesuai dengan tujuan yang diharapkan.
Resiko
merupakan bentuk keadaan ketidakpastian tentang suatu keadaan yang akan terjadi
nantinya (future) dengan keputusan yang diambil berdasarkan berbagai
pertimbangan pada saat ini. Manajemen resiko adalah proses pengukuran atau
penilaian resiko serta pengembangan strategi pengelolaannya.
Jenis Resiko
Teknologi :
- Komponen
file tidak lengkap
- Sistem operasi tidak kompatibel, device tidak dikenal
- Perangkat keras tidak mendukung (mis: resolusi monitor, resolusi printer)
- Spesifikasi tidak memenuhi
- Kualitas Network dibawah standar kebutuhan
- Browser, software tidak memenuhi
Defenisi konseptual mengenai resiko : (Robert Charette)
1. Resiko berhubungan dengan kejadian di masa yg akan datang.
2. Resiko melibatkan perubahan (spt. perubahan pikiran, pendapat, aksi, atau
tempat)
3. Resiko melibatkan pilihan & ketidakpastian bahwa pilihan itu akan
dilakukan.
Strategi Resiko Reaktif vs Proaktif
Strategi reaktif memonitor proyek terhadap kemungkinan resiko.
Sumber2 daya dikesampingkan, padahal seharusnya sumber2 daya menjadi masalah
yang sebenarnya / penting. Strategi proaktif dimulai sebelum kerja teknis
diawali. Resiko potensial diidentifikasi, probabilitas & pengaruh proyek
diperkirakan, dan diprioritaskan menurut kepentingan, kemudian membangun suatu
rencana untuk manajemen resiko. Sasaran utama adalah menghindari resiko.
Resiko Perangkat Lunak
Karakteristik resiko :
1. Ketidakpastian
2. Kerugian
Kategori resiko :
• Resiko proyek
• Resiko teknis
• Resiko bisnis
Rekayasa Perangkat Lunak Bab 6 Halaman 2
Kategori resiko oleh Robert Charette :
• Resiko yang sudah diketahui
• Resiko yang dapat diramalkan
• Resiko yang tidak diharapkan
@ Resiko proyek
Resiko proyek mengancam rencana proyek. Bila resiko proyek menjadi kenyataan
maka ada kemungkinan jadwal proyek akan mengalami slip & biaya menjadi
bertambah. Resiko proyek mengidenifikasi :
- biaya – sumber daya
- jadwal – pelanggan
- personil (staffing & organisasi) – masalah persyaratan
@ Resiko teknis
Resiko teknis mengancam kualitas & ketepatan waktu PL yg akan dihasilkan.
Bila resiko teknis menjadi kenyataan maka implementasinya menjadi sangat sulit
atau tidak mungkin.
Resiko teknis mengidentifikasi :
- desain potensial – ambiquitas
- implementasi – spesifikasi
- interfacing – ketidakpastian teknik
- verivikasi – keusangan teknik
- masalah pemeliharaan – teknologi yg leading edge
@ Resiko bisnis
Resiko bisnis mengancam viabilitas PL yg akan dibangun. Resiko bisnis
membahayakan proyek atau produk.
Rekayasa Perangkat Lunak Bab 6 Halaman 3
resiko bisnis utama :
1. pembangunan produk atau sistem yg baik sebenarnya tdk pernah diinginkan oleh
setiap orang (resiko pasar)
2. pembangunan sebuah produk yg tidak sesuai dgn keseluruhan strategi bisnis
bagi perusahaan (resiko strategi)
3. Pembangunan sebuah produk dimana sebuah bagian pemasaran tidak tahu
bagaimana harus menjualnya.
4. Kehilangan dukungan manajemen senior sehubungan dg perubahan pd fokus atau
perubahan pd manusia (resiko manajemen)
5. Kehilangan hal2 yg berhubungan dgn biaya atau komitmen personal (resiko
biaya).
@ Resiko yg sudah diketahui adalah resiko yg dpt diungkap setelah dilakukan
evaluasi secara hati2 terhadap rencana proyek, bisnis, & lingkungan teknik
dimana proyek sedang dikembangkan, dan sumber informasi reliable lainnya.
seperti :
- tgl penyampaian yg tdk realitas
- kurangnya persyaratan yg terdokumentasi
- kurangnya ruag lingkup PL
- lingkungan pengembangan yg buruk
@ Resiko yg dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya.
Misalnya :
- pergantian staf
- komunikasi yg buruk dgn para pelanggan
- mengurangi usaha staff bila permintaan pemeliharaan
sedang berlangsung dilayani
Rekayasa Perangkat Lunak Bab 6 Halaman 4
@ Resiko yg tidak diharapkan
resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi
sebelumnya.
Identifikasi Resiko Identifikasi resiko dalah usaha sistematis untuk menentukan
ancaman terhadap rencana proyek. Tujuan identifikasi resiko : untuk menghindari
resiko bilamana mungkin, serta menghindarinya setiap saat diperlukan.
Tipe resiko :
1. resiko generic merupakan ancaman potensial pd setiap proyek PL.
2. resiko produk spesifik hanya dapat diidentifikasi dgn pemahaman khusus
mengenai teknologi, manusia, serta lingkungan yg spesifik terhadap proyek yg
ada.
Metode untuk mengidentifikasi resiko adalah menciptakan checklist item resiko.
Kategori checklist item resiko :
o resiko ukuran produk
o resiko yg mempengaruhi bisnis
o resiko yg dihubungkan dgn karakteristik pelanggan
o resiko definisi proses
o resiko teknologi yang akan dibangun
o resiko lingkungan pengembangan
o resiko yg berhubungan dgn ukuran dan pengalaman staf Rekayasa Perangkat Lunak
Bab 6 Halaman 5
@ Resiko ukuran produk
Resiko yg berhubungan dgn keseluruhan ukuran PL yg akan dibangun atau
dimodifikasi.
Checklist item resiko yg berhubungan dgn ukuran produk (PL) :
• ukuran produk diperkirakan dalam LOC atau FP ?
• tingkat kepercayaan dlm estimasi ukuran yg diperkirakan ?
• ukuran produk yg diestimasi dalam jumlah program, file, transaksi ?
• presentase deviasi dalam ukuran produk dari rata2 produk terakhir ?
• ukuran database yg dibuat atau digunakan oleh produk ?
• jumlah pemakai produk ?
• jumlah perubahan yg diproyeksikan ke persyaratan produk ? sebelum produk ?
setelah penyampaian ?
• jumlah PL yg digunakan kembali ?
Bila persentasie deviasi besar atau deviasinya sama, tetapi hasil yg lalu
sangat kurang dari yg diharapkan, maka resikonya tinggi.
@ Resiko yg mempengaruhi bisnis
Resiko yg berhubungan dengan batasan yg dibebankan oleh manajemen atau pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan pertimbangan bisnis
kadang mengalami konflik langsung dengan kenyataan teknis.
Checklist item resiko yg berhubungan dgn pengaruh bisnis :
Rekayasa Perangkat Lunak Bab 6 Halaman 6 Pengaruh produk terhadap hasil
perusahaan ?
• Visibilitas produk terhadap manajemen senior ?
• Kelayakan deadline penyampaian ?
• Jumlah pelanggan yg akan menggunakan produk & konsistensi
• kebutuhan relatif mereka dengan produk tersebut ? Jumlah produk / sistem lain
dgn apa produk ini harus dapat saling dioperasikan ?
• Kepintaran pemakai akhir ?
• Jumlah dan kualitas dokumentasi produk yg harus diproduksi & disampaikan
kepada pelanggan ?
Batasan pemerintahan pada konstruksi produk ?
• Biaya yg berhubungan dgn penyampaian yg terlambat ?
• Biaya yg berhubungan dgn produk defektif ?
• Bila ada persentase deviasi yang besar atau jika jumlahnya sama, tetapi hasil
sebelumnya sangat kurang dari yg diharapkan, maka resiko tinggi.
@ Resiko yg dihubungkan dgn karakteristik pelanggan
Resiko yg berhubungan dengan kepintaran pelanggan & kemampuan pengembang
untuk berkomunikasi dgn pelanggan dgn cara yg cepat.
Karakteristik pelanggan :
- Pelanggan mempunyai keinginan yg berbeda.
- Pelanggan memiliki kepribadian yg berbeda.
- Pelanggan memiliki hubungan yg bervariasi dgn pemasok.
- Pelanggan juga kadang-kadang bertentangan.
Karakteristik pelanggan mempengaruhi kemampuan tim PL untuk menyelesaikan suatu
proyek tepat waktu & sesuai anggaran.
Rekayasa Perangkat Lunak Bab 6 Halaman 7 Checklist item resiko yg berhubungan
dgn karakteristik pelanggan:
• Pernahkah anda sebelumnya bekerja dengan pelanggan ?
• Apakah pelanggan memiliki gagasan yg solid mengenai apa yg diperlukannya ?
sudahkah pelanggan menggunakan waktunya untuk menuliskannya ?
• Apakah pelanggan akan setuju dgn penggunaan waktu didalam pertemuan
pengumpulan persyaratan formal (bab 11) utk mengidentifikasi ruang lingkup
proyek ?
• Apakah pelanggan bersedia membangun sambungan komunikasi cepat dgn pengembang
?
• Apakah pelanggan bersedia berpartisipasi dalam kajian ?
• Apakah pelanggan secara teknis pandai dlm area produk tsb?
• Apakah pelanggan bersedia membiarkan orang2 melakukan pekerjaan mereka ?
• Apakah pelanggan memahami proses perangkat lunak tsb ?
Bila setiap jawaban dari pertanyaan diatas adalah ‘tidak’, maka investigasi
lebih jauh harus dilakukan utk memperkirakan potensi resiko.
@ Resiko definisi proses
Bila kualitas merupakan sebuah konsep yg disetujui sbg hal yg penting tetapi
tidak tidak ada yg berintdak untuk mencapainya dengan cara yg dapat yg
dilakukan, maka proyek tersebut beresiko.
Masalah-masalah proses
• Apakah manajemen senior anda mendukung suatu pernyataan kebijaksanaan yg
menekankan pentingnya suatu proses standar untuk pengembangan proses ?
• Sudahkah organisasi anda mengembangkan suatu diskripsi tertulis mengenai
proses PL yg akan digunakan pd proyek ini ?
Rekayasa Perangkat Lunak Bab 6 Halaman 8
• Apakah anggota2 staf ‘ditugasi’ ke proses PL pd saat PL didokumentasi &
bersedia menggunakannya ?
• Apakah proses PL digunakan untuk proyek lain ?
• Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian
serangkaian kursus pelatihan RPL bagi para manajer dan staf teknik ?
• Apakah standar RPL yg diterbitkan disediakan utk setiap pengembang PL &
manajer PL ?
• Sudahkah dokumen outline & contoh2 dikembangkan untuk semua yg ditentukan
sebagai bagian yg dapat disampaikan sebagai bagian dari proses PL ?
• Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain, dan
kode dilakukan secara reguler ?
• Apakah kajian teknis formal terhadap prosedur pengujian & test case
dilakukan secara reguler ?
• Apakah hasil dari masing2 kajian teknis formal didokumentasikan, termasuk
kesalahan yg ditemukan & sumber daya yg digunakan ?
• Apakah mekanisme utk memastikan bahwa kerja yg dilakukan pd suatu proyek
sesuai dengan standar RPL ?
• Apakah manajemen konfigurasi digunakan utk memelihara konsistensi diantara
_ystem/persyaratan PL, desain, kode, dan test case ?
• Apakah digunakan suatu mekanisme utk mengontrol perubahan ke persyaratan
pelanggan yg mempengaruhi PL ?
• Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan, dan
rencana pengembangan PL yg didokumentasikan untuk masing2 subkontrak ?
• Apakah ada prosedur untuk menelusuri & mengkaji kinerja subkontrak ?
Masalah-masalah teknis
Rekayasa Perangkat Lunak Bab 6 Halaman 9
• Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi
diantara pelanggan & pengembang ?
• Apakah metode spesifik digunakan untuk analisis PL ?
• Apakah anda melihat suatu metode spesifik untuk data & desain arsitektur
?
• Apakah lebih dari 90% dari kode anda ditulis dgn bahasa orde yg lebih tinggi
?
• Apakah konvensi spesifik utk dokumentasi kode didefinisikan & digunakan ?
• Apakah anda menggunakan metode spesifik utk desain test case?
• Apakah digunakan peranti PL utk mendukung perencanaan & aktivitas
penelusuran ?
• Apakah digunakan peranti PL manajemen konfigurasi utk me-ngontrol &
menelusuri aktivitas perubahan diseluruh proses PL ?
• Apakah digunakan peranti PL utk mendukung analisis PL & desain proses ?
• Apakah digunakan peranti utk menciptakan prototipe PL ?
• Apakah digunakan peranti PL utk mendukung proses pengujian ?
• Apakah peranti PL digunakan utk mendukung produksi dan manajemen dokumentasi
?
• Apakah metrik kualitas dikumpulkan bagi semua proyek PL ?
• Apakah metrik produktivitas dikumpulkan bagi semua proyek PL?
Bila mayoritas jawaban terhadap pertanyaan tsb adalah `tidak`, maka proses PL
lemah dan berisiko tinggi.
@ Resiko teknologi yang akan dibangun
Rekayasa Perangkat Lunak Bab 6 Halaman 10
Resiko yg berhubungan dgn kompleksitas sistem yg akan dibangun dan `kebaruan`
teknologi yg dikemas oleh system. Checklist item resiko yg berhubungan dengan
teknologi yg akan dibangun :
• Apakah teknologi yg akan dibangun adalah hal yg baru untuk organisasi anda?
• Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi
input atau output?
• Apakah PL berinterface dgn perangkat keras baru atau belum terbukti?
• Apakah PL yg akan dibangun ber-interace dgn produk PL yg dipasok oleh vendor
yg belum terbukti?
• Apakah PL yg akan dibangun ber-interface dgn suatu system database yg fungsi
kinerjanya belum dibuktikan di dalam area aplikasi ini?
• Apakan diperlukan interface pemakai khusus oleh persyaratan produk?
• Apakah persyaratan untuk produk memerlukan kreasi komponen program yg tidak
sama dengan yg dikembangkan terakhir oleh organisasi anda?
• Apakah persyarata memerlukan pemakaian analisis, desain atau metode pengujian
baru?
• Apakah persyaratan memerlukan metode pengembangan PL tdk konvensional, spt
metode formal, pendekatan Al-based dan jaringan syaraf buatan?
• Apakah persyaratan meletakkan batasan kinerja yg eksesif pada produk
tersebut?
• Apakah pelanggan tidak yakin pada fungsionalitas yg diminta dapat
’dilakukan’?
Bila jawaban dari pertanyaan2 di atas adalah ’ya’, penyelidikan lebih lanjut
harus dilakukan untuk memperkirakan risiko potensial.
Rekayasa Perangkat Lunak Bab 6 Halaman 11
@ Resiko lingkungan pengembangan
Resiko yg berhubungan dgn keberadaan & kualitas peranti yg akan digunakan
untuk membangun produk. Lingkungan proses PL mendukung tim proyek, proses dan
produk.
Lingkungan yg salah dapat menjadi sumber resiko yg penting.
Checklist item resiko yg berhubungan dengan lingkungan
pengembangan :
• Apakah peranti manajemen proyek dapat diperoleh?
• Apakah peranti manajemen proses dapat diperoleh?
• Apakah peranti untuk analisis dan desain dapat diperoleh?
• Apakah peranti analisis dan desain penyampaian metode sesuai bagi produk yg
akan dibangun?
• Apakah kompiler atau generasi kode dapat diperoleh dan sesuai untuk produk yg
akan dibangun?
• Apakah peranti pengujian dapat diperoleh dan sesuai untuk produk yg akan
dibangun?
• Apakah peranti manajemen konfigurasi PL dapat diperoleh?
• Apakah lingkungan menggunakan suatu database atau tempat penyimpanan?
• Apakah semua peranti PL dapat diintegrasikan satu dgn lainnya?
• Sudahkah anggota tim proyek menerima pelatihan dgn masing2 peranti?
• Apakah ada pakar lokal untuk menjawab pertanyaan2 mengenai peranti tersebut?
• Apakah bantuan dan dokumentasi on-line bagi peranti memadai?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah ’tidak’, berarti
lingkungan pengembangan PL lemah dan berisiko tinggi.
Rekayasa Perangkat Lunak Bab 6 Halaman 12
@ Resiko yg berhubungan dgn ukuran & pengalaman staf
Resiko yg berhubungan dgn keseluruhan teknik & pengalaman proyek dari RPL
yg akan melakukan tugas tsb. Checklist item resiko yg berhubungan dengan ukuran
& pengalaman staf :
• Apakah orang2 terbaik dapat diperoleh?
• Apakah orang2 tsb memiliki gabungan ketrampilan yg benar?
• Apakah orang2 yg ada mencukupi?
• Apakah staf dimasukkan ke dalam seluruh durasi proyek?
• Akankah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini?
• Apaka staf memiliki pengharapan yg tepat mengenai pekerjaan yg ada sekarang?
• Sudahkah staf menerima pelatihan yg memadai?
• Apakah pergantian di antara staf akan cukup rendah untuk memungkinkan
kontinuitas?
Bila jawaban terhadap pertanyaan2 tsb adalah ’tidak’, maka penyelidikan lebih
lanjut harus dilakukan untuk memperkirakan risiko potensial.
Komponen Risiko dan Driver Pedoman untuk mengidentifikasi risiko PL dan pengurangannya
yaitu
menghendaki agar manajer proyek mengidentifikasi risiko driver yg mempengaruhi
komponen risiko PL – kinerja, biaya, dukungan dan jadwal.
Komponen risiko didefinisikan dgn cara sbb :
Rekayasa Perangkat Lunak Bab 6 Halaman 13
• Risiko kinerja – tingakat ketidakpastian dimana produk akan memenuhi
persyaratannya dan cocok dgn penggunaannya.
• Risiko biaya – tingkat ketidakpastian dimana biaya proyek akan dijaga
• Risiko dukungan – tingkat ketidakpastian dimana PL akan mudah dikoreksi,
disesuaikan dan ditingkatkan.
Manajemen
Proyek
Manajemen
proyek adalah cara mengorganisir dan mengelola sumber penghasilan yang penting
untuk menyelesaikan proyek.
Hal pertama
yang harus dianggap sebagai manajemen proyek adalah bahwa proyek ini diantarkan
dengan batasan yang ada. Hal kedua adalah kemungkinan terbaik distribusi sumber
daya. Manajemen proyek adalah seni mengontrol baik hal selama proyek, dari
sejak dimulai sampai selesai.
·
PMBOK : fondasi
dasar untuk memahami manajemen proyek.
·
Project Integration
Management : focus mengkoordinasikan perencanaan proyek, eksekusi, dan control
perubahan.
·
Project Scope
Management : jaminan bahwa kerja proyek telah akurat dan lengkap dan berjalan
sesuai rencana.
·
Project Time
Management : penting untuk mengembangkan, mengawasi, dan mengolah jadwal
proyek.
·
Project Cost
Management : menetapkan budget yang lengkap dan telah disetujui.
·
Project Quality
Management : focus pada perencanaan, pengembangan, pengolahan lingkungan yang
memungkinkan proyek untuk memenuhi harapan stakeholder.
·
Project Human
Resources Management : focus pada membuat dan mengembangkan tim proyek.
·
Project
Communication Management : menjamin penyampaian informasi secara akurat dan
tepat waktu pada stakeholder.
·
Project Risk
Management : berfokus pada identifikasi dan respon pada resiko project.
·
Project
Procurement Management : memungkinkan pengadaan sumber daya di luar organisasi.
3.
Pengertian
Business Case dan Tahapan dalam pengembangan Business Case!
·
Business Case :
menyediakan analisis nilai organisasi, biaya dan keuntungan, dan resiko dari
beberapa alternative.
Tahapan
:
·
Select Core Team
: mengumpulkan para ahli menjadi 1 tim.
·
Define Measurable
Organisational Value : Menetapkan goal, dimana goal tersebut harus : dapat
diukur, menyediakan manfaat bagi perusahaan, disetujui oleh stakeholder, dapat
diverifikasi.
·
Identify
Alternatives : menetapkan alternative penyelesaian karena tidak mungkin 1 hal
dapat menjawab semua masalah.
·
Define
feasibilities and assess risk : tiap alternative harus dianalisa resikonya dan
apakah tiap alternative itu bermanfaat.
·
Define Total Cost
of Ownership : menetapkan laba perusahaan.
·
Define total
benefit of ownership : menetapkan laba perusahan.
·
Propose and
support recommendation : mendukung alternative yang telah ditentukan.
Potential
Area :
·
Strategic
·
Kemungkinan pasar
yang baru
·
Transformasi
untuk berkompetisi dalam pasar yang baru.
·
Meningkatkan
bagian dalam pasar.
·
Customer
·
Makin banyak
pilihan produk dan layanan.
·
Menerima pelayanan
yang lebih baik.
·
Transaksi lebih
efektif dan efisien.
·
Finansial
·
Keuntungan
bertambah
·
Operational
·
Biaya operasi
lebih rendah.
·
Meningkatkan
efektivitas.
·
Meningkatkan SCM.
·
Social
·
Pendidikan
·
Keamanan
·
Kesehatan
·
Lingkungan
4.
Meliputi hal apa
saja yang termasuk di dalam business case template!
·
Cover page
·
Executive summary
·
Deskripsi singkat
dari masalah & kesempatan.
·
Goal dari segi
perusahaan.
·
MOV dan bagaimana
hubungannya dengan strategi goal perusahaan.
·
Penjelasan tiap
pilihan alternative.
·
Penjelasan alternative
terpilih.
·
Introduction
·
Situasi saat ini.
·
Penjelasan
masalah dan kesempatan.
·
MOV
·
Bagaimana
mencapai MOV
·
Sasaran business
case
·
Alternatives
·
Analysis of
Alternative
·
Proposed
recommendation