“ Sistem Inventori Tugas Akhir

Manajemen Proyek
Gudang “ ~Kelompok 5~

- Adelia Pramhesti
- Resti Amelia
- Stepanie Clasinski M
- Muhammad A Rahman
- Wahyu Tri Muhammad
- Stiven Huawei
- Chandra Pratama Putra
 Deskripsi Permasalahan

a. Perusahaan masih menggunakan teknik manual untuk pendataan

administrasi barang-barang logistik
b. Belum jelas atau konkretnya jumlah barang yang keluar masuk
c. Pemesanan barang yang stoknya akan habis sulit diprediksi
d. Tidak bisa melakukan opname barang
e. Pengelompokan barang sulit dilakukan
f. Kesulitan dalam mengatur jumlah barang dalam jumlah banyak
g. Tidak efisien dalam mengatur pendistribusian barang
 Deskripsi Permasalahan

Software “ Triple X“ merupakan solusi yang tepat untuk

membantu staff dalam mengatur persediaan barang masuk
dan keluar. Software ini dirancang untuk mendata barang
yang masuk dan yang keluar, mendata jumlah barang yang
masuk, jenis barang, jumlah barang dan mendata kualitas
barang yang ada.
 Deskripsi Sistem Informasi Inventori Gudang

Sistem ini dirancang untuk memasukkan sebagian data

barang seperti nama barang, warna, jumlah, tanggal
masuk barang dan kondisi barang. Didalam sistem ini
terdapat tiga menu utama yaitu New, Look, dan Out. Di
menu New user dapat menginput data barang seperti nama
barang, jumlah barang dll. Menu Look, kita dapat melihat
hasil data barang yang kita input dan serta menu print
untk print hasil inputan kita.
 Struktur Organisasi Tim
Project
Manager

Database Interface Dokumentasi

Sistem Analis Programmer
Designer Designer Sistem

Quality Teknisi
Trainer
Assurance Komputer
 PROPOSE STAKE HOLDER
Identifikasi Stakeholder
Anggota stakeholder yang terlibat dalam proyek aplikasi Sistem Informasi Inventori Gudang ini terdiri dari tim proyek, PT. X , dan pengguna akhir aplikasi Sistem
Informasi Inventori Gudang, yaitu
A. Tim Proyek terdiri dari:
1. Project Manager
2. Sistem Analis
3. Database Designer
4. Interface Designer
5. Programmer
6. Dokumentasi Sistem
7. Quality Assurance
8. Trainer
9. Teknisi Komputer
B. Pihak PT X
10. Direktur Utama
11. Kepala Penjualan
12. Kepala Gudang
13. Kepala Akunting
14. Kepala Pengadaan Barang
C. Pengguna akhir :
15. Administrator
16. Pejabat Fungsional
 PROPOSE STAKE HOLDER
Identifikasi Stakeholder
Anggota stakeholder yang terlibat dalam proyek aplikasi Sistem Informasi Inventori Gudang ini terdiri dari tim proyek, PT. X , dan pengguna akhir aplikasi Sistem
Informasi Inventori Gudang, yaitu
A. Tim Proyek terdiri dari:
1. Project Manager
2. Sistem Analis
3. Database Designer
4. Interface Designer
5. Programmer
6. Dokumentasi Sistem
7. Quality Assurance
8. Trainer
9. Teknisi Komputer
B. Pihak PT X (Project Sponsor)
10. Direktur Utama
11. Kepala Penjualan
12. Kepala Gudang
13. Kepala Akunting
14. Kepala Pengadaan Barang
C. Pengguna akhir :
15. Administrator
16. Pejabat Fungsional
 Struktur Organisasi Tim
Project
Manager

Database Interface Dokumentasi

Sistem Analis Programmer
Designer Designer Sistem

Quality Teknisi
Trainer
Assurance Komputer
 Deskripsi Tugas
Jabatan/Peran Tanggung jawab & Wewenang
Merencanakan, melaksanakan dan mengawasi
Project Manager
proyek
Menganalisis proses bisnis dan membuat
Sistem Analis
pemodelan
Database Designer Merancang dan mengelola database
Merancang tampilan aplikasi dan input/output
Interface Designer
sistem
Programmer Membuat kode program
Dokumentasi
Membuat dokumentasi sistem
Sistem
Quality Assurance Menguji kualitas sistem

Trainer Memberikan pelatihan kepada pengguna

Teknisi Komputer Melakukan maintenance komputer

BASELINE JADWAL DAN WORK
BREAKDOWN STRUCTURE
 Untuk mengerjakan Proyek Membangun Sistem Informasi
Manajemen Kepegawaian ini diperlukan waktu 89 hari
kerja. Total waktu yang disediakan untuk melakukan
pembangunan proyek ini, dari mulai pembukaan proyek
sampai dengan penutupan proyek adalah 4 bulan atau
112 hari kerja. Baseline Jadwal dan WBS terlampir dalam
LAMPIRAN 1: WORK BREAKDOWN STRUCTURE DAN
BASELINE JADWAL.
 Rencana Manajemen Perubahan
Prosedur Kontrol Perubahan:

• Setiap modifikasi yang telah disetujui, ataupun perubahan pada jadwal dan biaya proyek harus mengacu pada
prosedur berikut.
• Pengajuan perubahan dapat berasal dari setiap anggota tim apabila diperlukan, terutama untuk perubahan yang
akan mempengaruhi jadwal dan ruang lingkup kerja.
• Persetujuan pada Form Permintaan Perubahan/Changes Request Form (CRF) menunjukkan persetujuan
terhadap perubahan pada jadwal.

Pengajuan Perubahan:

• Suatu perubahan dapat diajukan ke manajer proyek melalui komunikasi formal (meeting reguler) ataupuan non-
formal (melalui bentuk komunikasi lainnya).
• Mengisi Form Permintaan Perubahan (CRF) - (lihat LAMPIRAN 2.1) - untuk diajukan sebagai usulan
perubahan.
• Catat CRF pada Catatan Permintaan Perubahan - (lihat LAMPIRAN 2.2).

Monitor Perubahan:

• Apabila Form Permintaan Perubahan telah disetujui, pekerjaan dapat dimulai.

• Project Manager atau manajer proyek akan mengubah jadwal proyek atau rencana kerja untuk mengakomodasi
perubahan yang telah disetujui dan mempresentasikannya dalam meeting kemajuan proyek untuk disetujui.
• Kemajuan dalam kontrol perubahan akan dilaporkan dalam meeting proyek. Project Manager harus
menanda tangani Form Permintaan Perubahan apabila perubahan telah diselesaikan.
 Quality Plan
 Rencana manajemen mutu pada proyek aplikasi sistem informasi manajemen
kepegawaian ini yaitu menggunakan metode check list, yaitu dengan mengecek
setiap tahap pelaksanaan proyek yang sesuai dengan standar ISO 9000 demi
memberikan kepuasan dengan terpenuhinya semua kebutuhan pelanggan. ISO
9000 adalah suatu kumpulan standar untuk sistem manajemen mutu. ISO 9000
dirumuskan oleh TC 176 ISO, yaitu suatu organisasi internasional atau komite
yang mengembangkan standar manajemen mutu dan kualitas. Daftar
pelaksanaan proyek yang dinilai telah sesuai dengan standar ISO 9126
terlampir dalam LAMPIRAN 4: RENCANA MANAJEMEN MUTU.

1. Mulai proyek
2. Perencanaan
3. Pelaksanaan
3.1. Analisa Sistem
3.2. Desain Database
Sistem
3.3. Desain Antarmuka
sistem
3.4. Koding dan Testing
3.5. Dokumentasi Sistem
3.6. Pembuatan Manual
Sistem
4. Implementasi
5. Penutupan Proyek
Total biaya proyek
PROPOSE BUDGET
Rp 33.560.000 Honor untuk project manager, sistem analis, dan database designer.
Rp 15.000.000 Honor untuk project manager, sistem analis, dan database designer.
Honor untuk project manager, sistem analis, dan database designer,
Rp 42.549.000
programmer, dokumentasi sistem, interface designer, quality assurance
Rp 8.000.000 Honor untuk dokumentasi sistem, project manager, sistem analis.
 
Rp 4.250.000
Honor untuk database designer.
 
Rp 4.060.000
Honor untuk interface designer
Rp 17.500.000 Honor untuk programmer dan quality assurance
Rp 500.000 Honor untuk dokumentasi sistem.
 
Rp 3.000.000
Honor helpdesk dan dokumentasi sistem.
Rp22.516.000 Honor untuk trainer dan teknisi komputer.
Rp7.500.000 Honor untuk project manager.
Rp. 121.125.500
 RENCANA MANAJEMEN PERUBAHAN

Prosedur Kontrol Perubahan:

• Setiap modifikasi yang telah disetujui, ataupun perubahan pada jadwal dan biaya proyek harus mengacu pada
prosedur berikut.
• Pengajuan perubahan dapat berasal dari setiap anggota tim apabila diperlukan, terutama untuk perubahan yang akan
mempengaruhi jadwal dan ruang lingkup kerja.
• Persetujuan pada Form Permintaan Perubahan/Changes Request Form (CRF) menunjukkan persetujuan
terhadap perubahan pada jadwal.

Pengajuan Perubahan:

• Suatu perubahan dapat diajukan ke manajer proyek melalui komunikasi formal (meeting reguler) ataupuan non-
formal (melalui bentuk komunikasi lainnya).
• Mengisi Form Permintaan Perubahan (CRF) - (lihat LAMPIRAN 2.1) - untuk diajukan sebagai usulan perubahan.
• Catat CRF pada Catatan Permintaan Perubahan - (lihat LAMPIRAN 2.2).

Monitor Perubahan:

• Apabila Form Permintaan Perubahan telah disetujui, pekerjaan dapat dimulai.

• Project Manager atau manajer proyek akan mengubah jadwal proyek atau rencana kerja untuk mengakomodasi
perubahan yang telah disetujui dan mempresentasikannya dalam meeting kemajuan proyek untuk disetujui.
• Kemajuan dalam kontrol perubahan akan dilaporkan dalam meeting proyek. Project Manager harus menanda
tangani Form Permintaan Perubahan apabila perubahan telah diselesaikan.
 Communication plan (1)
 Perencanaan Komunikasi
Perencanaan komunikasi menjabarkan kebutuhan komunikasi reguler antar anggota
tim yang terlibat dalam pengerjaan proyek Pembangunan Sistem Informasi Inventori
Gudang. Komunikasi tidak harus dilakukan secara formal saja, komunikasi bisa
dilakukan secara terbuka dan informal untuk memfasilitasi transfer pengetahuan
(knowledge transfer) antar semua pihak yang terlibat/berkepentingan. Untuk
perencanaan komunikasi yang bersifat formal, akan dicantumkan pada LAMPIRAN
3: PERENCANAAN KOMUNIKASI yang menggambarkan komunikasi reguler
yang dianggap penting untuk memastikan adanya informasi yang tepat,
keterlibatan, dukungan dan manajemen proyek yang efektif.
 Communication plan (2)
 Persiapan Pertemuan
 Mendistribusikan agenda meeting, selambat-lambatnya sehari sebelumnya. Pembahasan topik berdasarkan
urutan kepentingan dimulai dengan topik yang mudah dan setiap topik diberikan alokasi waktu.
 Mendistribusikan materi meeting, agenda, serta informasi lokasi dan waktu.
 Setiap anggota tim proyek bertanggung jawab untuk melakukan persiapan, hadir dan berpartisipasi aktif
dalam meeting.
 Pemimpin meeting dan fasilitator memastikan meeting dapat berjalan pada jalurnya dan efektif, sehingga
tujuan meeting dapat dicapai.
 Pemimpin meeting akan menunjuk seorang notulis untuk membuat dokumentasi meeting dan
mendistribusikannya dengan tepat.
 Meeting paling sedikit membahas topik berikut:
 Kemajuan proyek
 Aktivitas yang akan segera dilakukan
 Pembahasan ulang kontrol perubahan (change review)
 Risk Identification & Migation (1)
 Work breakdown structure
Identifikasi Resiko
 Pendekatan pada deliverables setiap unit kerja secara detail.
Dengan cara ini identifikasi terhadap risiko bisa sampai ke level
yang sangat detail.
Kontrol Resiko
 Resiko kecil, karena WBS dibuat secara detail yaitu sampai level
5.
 Penempatan SDM
Identifikasi Resiko
 Setiap pekerjaan yang spesifik dan hanya dapat dilakukan oleh
orang tertentu meningkatkan risiko proyek, apabila orang
tersebut berhalangan untuk hadir
 Resiko kecil, karena hamper setiap tim memiliki multiple skill
yang dapat merangkap pekerjaan lain.
Risk Identification & Migation (2)
 Estimasi biaya dan waktu
Identifikasi Resiko
 Estimasi yang terlalu kasar dan terburu-buru dapat
meningkatkan risiko proyek
Kontrol Resiko
 Resiko kecil, karena pembuatan aplikasi sejenis sudah
sering dikerjakan oleh tim proyek, sehingga sudah
berpengalaman mengenai adanya resiko.
LAMPIRAN 1: BASELINE JADWAL DAN WORK BREAKDOWN
STRUCTURE (1)
LAMPIRAN 1: BASELINE JADWAL DAN WORK BREAKDOWN
STRUCTURE (2)
 LAMPIRAN 1: BASELINE JADWAL DAN WORK BREAKDOWN
STRUCTURE (3)

No. Level WBS Code Activity Duration (hari) Predesesor

1 1 1 Sistem Informasi Kepegawaian 89 hari  
PERUSAHAAN X
2 2 1.1 Mulai Proyek 8 hari  
3 3 1.1.1 Kick off meeting 3 hari  
4 3 1.1.2 Membuat project charter 5 hari 3
5 3 1.1.3 Project charter ditandatangani 0 hari 4
6 2 1.2 Perencanaan 7 hari  
7 3 1.2.1 Membuat proposal proyek 5 hari 5
8 3 1.2.2 Finalisasi proposal proyek 2 hari 7
9 3 1.2.3 Proposal disetujui 0 hari 8
10 2 1.3 Pelaksanaan 65 hari  
11 3 1.3.1 Analisa sistem 21 hari  
12 4 1.3.1.1 Survei dan interview dengan stakeholder 4 hari 9
13 4 1.3.1.2 Pengumpulan data primer dan sekunder 3 hari 12
14 4 1.3.1.3 Analisa sistem berjalan 7 hari 13
15 4 1.3.1.4 Pemodelan proses bisnis 3 hari 14
16 4 1.3.1.5 Review hasil analisis dengan stakeholder 1 day 15
17 4 1.3.1.6 Perbaikan analisis 2 hari 16
18 4 1.3.1.7 Review hasil perbaikan analisis 1 day 17
19 4 1.3.1.8 Hasil analisa sistem disetujui 0 hari 18
 LAMPIRAN 1: BASELINE JADWAL DAN WORK
BREAKDOWN STRUCTURE (4)

No. Level WBS Code Activity Duration (hari) Predesesor

20 3 1.3.2 Desain database sistem 5 hari  
21 4 1.3.2.1 Perancangan database 3 hari 19
22 4 1.3.2.2 Pengujian struktur database 1 day 21
23 4 1.3.2.3 Perbaikan rancangan database 1 day 22
24 4 1.3.2.4 Struktur database ditetapkan 0 hari 23
25 3 1.3.3 Desain antarmuka sistem 7 hari  
26 4 1.3.3.1 Pengembangan antarmuka sistem 5 hari 24
27 4 1.3.3.2 Review rancangan antarmuka dengan stakeholder 1 day 26
28 4 1.3.3.3 Perbaikan rancangan antarmuka 1 day 27
29 4 1.3.3.4 Desain antarmuka sistem disetujui 0 hari 28
30 3 1.3.4 Koding dan Testing 23 hari  
31 4 1.3.4.1 Melakukan pengkodingan 21 hari 29
32 4 1.3.4.2 Review koding (test unit) 2 hari 31
33 4 1.3.4.3 Program selesai dibuat 0 hari 32
34 3 1.3.5 Dokumentasi sistem 5 hari  
35 4 1.3.5.1 Penyusunan dokumentasi sistem 5 hari 33
36 4 1.3.5.2 Dokumentasi sistem selesai dibuat 0 hari 35
37 3 1.3.6 Pembuatan manual sistem 4 hari  
38 4 1.3.6.1 Penyusunan manual sistem 4 hari 36
 LAMPIRAN 1: BASELINE JADWAL DAN WORK
BREAKDOWN STRUCTURE (5)
No. Level WBS Code Activity Duration (hari) Predesesor
39 4 1.3.6.2 Dokumen manual sistem selesai dibuat 0 hari 38
40 2 1.4 Implementasi 5 hari  
41 3 1.4.1 Instalasi software 2 hari 39
42 3 1.4.2 Instalasi sistem ke server 1 hari 41
43 3 1.4.3 Setting sistem dan database 1 hari 42
44 3 1.4.4 Sistem terimplementasi 0 hari 43
45 3 1.4.5 Pelatihan operator dan admin 1 hari  
46 4 1.4.5.1 Menyelenggarakan pelatihan 1 hari 43
47 4 1.4.5.2 Pelatihan selesai 0 hari 46
48 2 1.5 Penutupan proyek 4 hari  
49 3 1.5.1 Penyusunan laporan akhir 1 hari 47
50 3 1.5.2 Penyusunan dokumen proyek internal 1 hari 49
51 3 1.5.3 Mendapatkan persetujuan stakeholder 1 hari 50
52 3 1.5.4 Pembagian dokumen proyek internal 1 hari 51
53 3 1.5.5 Proyek selesai 0 hari 52
LAMPIRAN 2: RENCANA MANAJEMEN PERUBAHAN

1. Form Permintaan Perubahan (Changes Request Form)

FORMULIR PERMINTAAN PERUBAHAN

(CHANGES REQUEST FORM)
 
No. Formulir :
Nama Proyek :
Manajer Proyek :
Bidang :
Nama Pengusul :
Tanggal :

Deskripsi Perubahan yang diusulkan/diinginkan:  

Usul Diterima/Tidak?  
 

Bila tidak berikan alasan

Diajukan oleh: Disetujui oleh:
   
   
   
Tanggal: Tanggal:
LAMPIRAN 2: RENCANA MANAJEMEN PERUBAHAN

2. Catatan Permintaan Perubahan (Changes Request Log)

DAFTAR PERMINTAAN PERUBAHAN

(CHANGES REQUEST LOG)

Nama Proyek :
Manajer Proyek :
Bidang :
        Tanggal
No. Form Deskripsi Nama Pengusul Tanggal Usulan  
Permintaan Persetujuan

Keterangan : Usulan yang didaftarkan pada Daftar Permintaan Perubahan adalah usulan yang diterima saja.
LAMPIRAN 2 : RENCANA MANAJEMEN MUTU (1)
No Deskripsi Proyek Cek Mutu
1 Analisis Sistem  
2 Survei dan interview dengan stakeholder -
3 Pengumpulan data primer dan sekunder -
4 Analisa sistem berjalan √
5 Pemodelan proses bisnis √
6 Review hasil analisis dengan stakeholder √
7 Perbaikan analisis √
8 Review hasil perbaikan analisis √
9 Desain Database Sistem  
10 Perancangan database √
11 Pengujian struktur database √
12 Perbaikan rancangan database √
13 Desain antarmuka sistem  
14 Pengembangan antarmuka sistem √
15 Review rancangan antarmuka dengan stakeholder √
16 Perbaikan rancangan antarmuka √
17 Koding dan Testing  
18 Melakukan pengkodingan √
 LAMPIRAN 3 : RENCANA KOMUNIKASI(1) : PERTEMUAN

Jenis Agenda Waktu Masukan Keluaran

Pertemuan
Pertemuan - Membahas rencana Sekali, - Rencana Manajemen - Catatan
Pembukaan kerja saat eksekusi Proyek Pertemuan
proyek pertama (MoM) &
kali Rencana Kerja

Pertemuan - Membahas/review Regular - Rencana Manajemen - MoM &

Tim status dan kemajuan Proyek Rencana Kerja
Proyek proyek - Laporan - Laporan
- Membahas rencana Kemajuan Kerja Kemajuan Kerja
kerja berikutnya (Project Progress yang disetujui
- Memantau & Report) &
Mengontrol perubahan kelengkapannya:
yang terjadi o Form/Catatan
- Me-review Rencana Permintaan
Kerja (Action Plan) yang Perubahan
telah dilakukan

Pertemuan - Transfer Pengetahuan Sekali - Rencana Kerja - MoM &

Penutupan - Membahas serah menjelang - Laporan Kemajauan Rencana Kerja
terima proyek penutupan proyek Kerja - Rencana Kerja
yang
diperbaharui
 LAMPIRAN 2 : RENCANA KOMUNIKASI(2) : PELAPORAN
(MEETING)
Jenis
Agenda Waktu Masukan Keluaran
Pertemuan
Laporan Kemajuan - Status Mingguan, - Tim Rapat Laporan
Proyek (Project - Work Progress setiap hari - Form Permintaan Kemajuan Proyek
Progress Report) Detail/Achievement Senin Perubahan (Project Progress
- Deliverable & Milestone - Daftar Permintaan Report)
- Daftar permintaan Perubahan
Perubahan
Status - Undangan Pertemuan Mingguan, - Tim Rapat Status Acara
Acara/Agenda - Usulan Acara/Agenda dikirim minimal - Form/Catatan Pertemuan (Status
Pertemuan (Status - Pekerjaan yang satu hari sebelum - Permintaan Meeting Agenda)
Meeting Agenda) belum Diselesaikan Pertemuan tim - Perubahan
dan Permintaan proyek
Perubahan
- Laporan status
aktivitas

Catatan Pertemuan - Agenda Setiap - Pertemuan/Rapat Catatan Rapat

(Minutes of - Isu yang dibahas pertemuan (MoM) & Rencana
Meeting) - Rencana Kerja, (regular, adhoc) Kerja
tanggal target
LAMPIRAN 3 : RENCANA MANAJEMEN MUTU (1)
No Deskripsi Proyek Cek Mutu
1 Analisis Sistem  
2 Survei dan interview dengan stakeholder -
3 Pengumpulan data primer dan sekunder -
4 Analisa sistem berjalan √
5 Pemodelan proses bisnis √
6 Review hasil analisis dengan stakeholder √
7 Perbaikan analisis √
8 Review hasil perbaikan analisis √
9 Desain Database Sistem  
10 Perancangan database √
11 Pengujian struktur database √
12 Perbaikan rancangan database √
13 Desain antarmuka sistem  
14 Pengembangan antarmuka sistem √
15 Review rancangan antarmuka dengan stakeholder √
16 Perbaikan rancangan antarmuka √
17 Koding dan Testing  
18 Melakukan pengkodingan √
LAMPIRAN 3 : RENCANA MANAJEMEN MUTU (2)
No Deskripsi Proyek Cek Mutu
19 Review koding (test unit) √
20 Dokumentasi sistem √
21 Penyusunan dokumentasi sistem √
22 Pembuatan manual sistem √
23 Penyusunan manual sistem √
24 Implementasi  
25 Instalasi software √
26 Instalasi sistem ke server √
27 Setting sistem dan database √
28 Instalasi software √
29 Pelatihan operator dan admin √
30 Penutupan proyek  
31 Penyusunan laporan akhir √
32 Penyusunan dokumen proyek internal √
33 Mendapatkan persetujuan stakeholder √
34 Pembagian dokumen proyek internal √
35 Penutupan proyek √
36 Penyusunan laporan akhir √