Project Management Plan: Perancangan Sistem Inventaris PT. Sumber Makmur Food Tbk

(1)

Management Plan

Perancangan Sistem Inventaris

PT. Sumber Makmur Food Tbk

Sarah Khairunnisa (1113091000007)

2016-04-22

(2)

CHANGE HISTORY

Tabel berikut ini berisi informasi perkembangan rencana manajemen proyek. Tabel berikut ini berisi informasi perkembangan rencana manajemen proyek.

Versi Penulis Versi Penulis Tanggal Tanggal revisi revisi dokumen dokumen Disetujui oleh

Disetujui oleh TanggalTanggal persetujuan

persetujuan AlasanAlasan V1.0 Sarah

V1.0 Sarah

Khairunnisa Khairunnisa

-

- Rayi Rayi PradonoPradono Iswara

Iswara

26/04/2016

26/04/2016 Pembuatan Pembuatan awalawal project plan project plan V1.1 Sarah V1.1 Sarah Khairunnisa Khairunnisa 01/05/2016

01/05/2016 Rayi Rayi PradonoPradono Iswara Iswara Penambahan Penambahan Scope Scope Management Management Plan dan WBS Plan dan WBS V1.2 Sarah V1.2 Sarah Khairunnisa Khairunnisa 07/06/2016

07/06/2016 Rayi Rayi PradonoPradono Iswara Iswara Penambahan Penambahan Risk Risk Management Management Plan Plan V1.3 Sarah V1.3 Sarah Khairunnisa Khairunnisa 20/06/2016

20/06/2016 Rayi Rayi PradonoPradono Iswara Iswara Melengkapi Melengkapi Project Project Management Management Plan Plan

(3)

CHANGE HISTORY

Tabel berikut ini berisi informasi perkembangan rencana manajemen proyek. Tabel berikut ini berisi informasi perkembangan rencana manajemen proyek.

Versi Penulis Versi Penulis Tanggal Tanggal revisi revisi dokumen dokumen Disetujui oleh

Disetujui oleh TanggalTanggal persetujuan

persetujuan AlasanAlasan V1.0 Sarah

V1.0 Sarah

Khairunnisa Khairunnisa

-

- Rayi Rayi PradonoPradono Iswara

Iswara

26/04/2016

26/04/2016 Pembuatan Pembuatan awalawal project plan project plan V1.1 Sarah V1.1 Sarah Khairunnisa Khairunnisa 01/05/2016

01/05/2016 Rayi Rayi PradonoPradono Iswara Iswara Penambahan Penambahan Scope Scope Management Management Plan dan WBS Plan dan WBS V1.2 Sarah V1.2 Sarah Khairunnisa Khairunnisa 07/06/2016

07/06/2016 Rayi Rayi PradonoPradono Iswara Iswara Penambahan Penambahan Risk Risk Management Management Plan Plan V1.3 Sarah V1.3 Sarah Khairunnisa Khairunnisa 20/06/2016

20/06/2016 Rayi Rayi PradonoPradono Iswara Iswara Melengkapi Melengkapi Project Project Management Management Plan Plan

(4)

TABLE OF CONTENT

CHANGE

CHANGE HISTORY ...HISTORY ... ... 11 TABLE

TABLE OF OF CONTENT ...CONTENT ... ... 22 1.

1. Introduction ...Introduction ... ... 44 1.1

1.1 Project Project Summary ...Summary ... ... 44 1.1.1

1.1.1 Purpose, Purpose, Scope, Scope, and and Objectives Objectives ... ... 44 1.1.2

1.1.2 Assumptions Assumptions and and Constrains Constrains ... ... 55 1.1.3

1.1.3 Project Project Deliverables Deliverables ... ... 66 1.1.4

1.1.4 Schedule Schedule and and Budget Budget Summary Summary ... ... 77 1.2

1.2 Evolution of Evolution of the the plan ...plan ... 7... 7 2.

2. Definitions Definitions ... ... 88 3.

3. Scope Scope Management Management Plan Plan ... ... 88 3.1

3.1 Scope Scope Definitions Definitions ... 8... 8 3.2

3.2 Work Work Breakdown Breakdown Structure ....Structure ... 9... 9 4.

4. Schedule/Time Schedule/Time Management ...Management ... 11... 11 4.1

4.1 Define Define Activities ...Activities ... ... 1111 4.2

4.2 Estimate Estimate Activity Activity Duration Duration ... .... 1313 4.3

4.3 Project Project Schedule ...Schedule ... ... 1313 5.

5. Cost/Budget Cost/Budget Management...Management... ... 1313 6.

6. Quality Quality Management...Management... ... 1515 6.1

6.1 Quality Quality Planning ...Planning ... ... 1515 6.2

6.2 Quality Quality Assurance Assurance ... 15... 15 6.3

6.3 Quality Quality Control ...Control ... ... 1515 7.

7. Human Human Resource Resource Management ..Management ... 17... 17 7.1

7.1 Job Job Description ...Description ... ... 1717 7.2

7.2 Internal Internal Structure ...Structure ... ... 1818 7.3

7.3 Roles Roles and and Responsibility ...Responsibility ... 18... 18 7.4

(5)

8. Communication Management ... 21

8.1 Communication Plan ... 21

8.2 Manage Communication ... 21

9. Risk Management Plan ... 23

9.1 Plan Risk Management ... 23

9.2 Identify Risk ... 23

9.3 Qualitative Risk Analysis ... 26

9.4 Quantitative Risk Analysis ... 27

9.5 Plan Risk Response ... 28

10. Procurement Management ... 30

(6)

1. Introduction

1.1 Project Summary

1.1.1 Purpose, Scope, and Objectives Ruang Lingkup Proyek

Nomor : SI-01

Nama Sistem : Sistem Inventaris PT. Sumber Makmur Food Tbk Singkatan : SISMF

PT. Sumber Makmur Food Tbk merupakan perusahaan yang bergerak di bidang produksi makanan. Jenis makanan yang di produksi yaitu makanan ringan tradisional. Ada puluhan macam produk yang diproduksi. Kegiatan operasional yang dilakukan oleh PT. Sumber Makmur Food mencakup seluruh tahapan proses produksi makanan, mulai dari pengolahan bahan baku hingga menjadi produk akhir yang siap dipasarkan.

Dalam melakukan kegiatan produksi, perusahan ini memerlukan waktu yang cukup lama untuk melakukan pendataan terhadap bahan baku yang masuk, pengecekan kualitas bahan baku, pendataan dan pengecekan stok barang, merekam transaksi penjualan dan pembelian, serta pendataan mutasi barang. Proses tersebut sampai saat ini masih dilakukan secara manual. Sistem yang berjalan saat ini masih menggunakan aplikasi Microsoft Access dengan single user sehingga mengurangi efektivitas dan efisiensi kinerja.

Sebagai salah satu perusahaan yang memproduksi ratusan produk setiap hari sudah sepantasnya PT. Sumber Makmur Food memiliki sistem inventaris untuk mempermudah pekerjaan serta meminimalisir kesalahan dalam pendataan yang masih dilakukan secara manual.

(7)

Tujuan Proyek

Tujuan proyek ini adalah membuat Sistem Inventaris berbasis web untuk mempermudah pengelolaan data inventaris barang produksi pada PT. Sumber Makmur Food Tbk.

Tujuan dari pembuatan Sistem Inventaris PT. Sumber Makmur Food Tbk ini adalah:

1. Mempermudah pendataan bahan baku yang masuk. 2. Mempermudah pendataan dan pengecekan stok barang.

3. Menangani data transaksi barang masuk dan keluar inventori. 4. Merekam data transaksi penjualan dan pembelian.

5. Mempermudah pengecekan kualitas produk.

6. Mencetak laporan transaksi sehingga menjadi lebih rapi dan cepat.

1.1.2 Assumptions and Constrains

Sistem yang akan dibuat merupakan web-based application dikarenakan aplikasi yang berbasis web memiliki keunggulan dapat diakses dimanapun-kapanpun. Selain itu, dengan menggunakan jaringan Intranet, maka proses instalasi pada tiap komputer tidak perlu

dilakukan. Sistem ini bisa diakses secara online melalui jaringan Intranet.

Pengguna sistem ini terdiri dari 3 actor , yaitu: admin, operator , serta supervisor . Admin yang dimaksud adalah staff bagian IT pada perusahaan PT. Sumber Makmur Food Tbk. Saat pertama kali user

mengakses sistem, maka diwajibkan untuk login terlebih dahulu. Admin dan supervisor dapat melihat daftar transaksi keluar-masuk barang yang belum terkonfirmasi sehingga harus dikonfirmasi oleh admin atau supervisor . Dalam sistem ini terdapat fitur penjualan untuk

(8)

mendata produk yang telah terjual. Fitur pembelian untuk mendata transaksi pembelian bahan baku dari supplier. Fitur mutasi barang untuk mendata produk yang dipindahkan dari ruang produksi ke gudang atau sebaliknya.

Batasan (Constraint )

1. Jadwal: Proyek SISMF harus diselesaikan tepat waktu sesuai dengan estimasi waktu yang telah ditentukan.

2. Biaya: Biaya pengembangan proyek SISMF harus sesuai dengan dana yang telah dialokasikan

3. Teknologi: Sistem harus dapat dijalankan pada perangkat yang sudah ada sehingga meminimalisir kebutuhan dukungan teknis. 4. Sistem ini dibatasi hanya pada proses pendataan bahan baku dan

stok barang, pendataan mutasi barang, dan merekam transaksi penjualan dan pembelian.

5. Pembuatan desain konsep dengan menggunakan UML (Unified Modelling Language), desain mockup menggunakan Adobe

Photoshop CS6.

6. Perancangan aplikasi dengan menggunakan software Notepad++ serta bahasa pemrograman PHP, menggunakan Framework Bootstrap 3, perancangan database dengan menggunakan MySQL.

7. Metode pengembangan sistem yang digunakan adalah metode Waterfall , dengan tahapan: Requirement Definition (Penentuan Kebutuhan), System Design (Desain Sistem), Implementation (Implementasi), Testing (Pengujian), dan Maintenance (Perawatan).

1.1.3 Project Deliverables

Sistem yang sudah selesai termasuk buku petunjuk penggunaan sistem (user manual ) akan dikirimkan dalam waktu 3 hari setelah

(9)

proyek selesai dan telah melalui tahap maintenance. 1.1.4 Schedule and Budget Summary

Estimasi waktu dan biaya yang diperlukan untuk pengembangan sistem adalah sebagai berikut:

Aktivitas Estimasi Waktu Estimasi Jumlah pekerja Biaya Initiate the Project 1 Minggu

(5 hari kerja ) 2 Orang Rp. 6.500.000 System

Requirement Analysis

2 Minggu

(10 hari kerja) 3 Orang Rp. 23.000.000 System Design

4 Minggu

(20 hari kerja) 4 Orang Rp. 56.000.000 Implementation

6 Minggu

(30 hari kerja) 7 Orang Rp. 74.500.000 Maintenance

2 Minggu

(10 hari kerja) 3 Orang Rp. 7.500.000 Close the

project

1 Minggu

(3 hari kerja) 2 Orang Rp. 2.100.000 TOTAL 16 Minggu _{22 Orang} Rp. 169.600.000

Total waktu yang dibutuhkan untuk mengembangkan sistem adalah 16 minggu, dan total biaya internal Rp. 169.600.000,- (Seratus Enam Puluh Sembilan Juta Enam Ratus Ribu Rupiah).

1.2 Evolution of the plan

Segala perubahan terhadap rencana manajemen proyek harus di setujui oleh kedua pihak sebelum diimplementasikan. Segala macam perubahan harus didokumentasikan untuk menjaga agar rencana

(10)

2. Definitions

1. SISMF : Sistem Inventaris PT. Sumber Makmur Food Tbk. 2. SMF : Sumber Makmur Food

3. PM : Project Manager 4. AL : Analyst Leader 5. SA : System Analyst 6. DL : Developer Leader 7. SD : Software Designer 8. PR : Software Developer/Programmer 9. DC : Documentation

3. Scope Management Plan

Tahapan untuk menentukan Scope Management ini meliputi : Scope Planning, Scope Definition, Create WBS, Scope Validations, dan Scope Control . Scope Planning merupakan proses pembuatan Scope Management Plan yang mendokumentasikan bagaimana ruang lingkup proyek akan ditentukan ( Defined ), dievaluasi (Validated ), dan dikendalikan (Controlled ) (PMBOK, 2013). Dokumen ini berisi tentang perencanaan dan pengaturan ruang lingkup proyek.

3.1 Scope Definitions

Ruang lingkup proyek dibuat agar proyek ini dapat berjalan sesuai jalurnya.

 Sistem yang dibuat adalah sistem baru, yang nantinya akan diimplementasikan pada PT. Sumber Makmur Food Tbk.

 Sistem yang dibuat merupakan web-based application.

 Sistem yang dijalankan membutuhkan komputer dengan aplikasi

web-browser .

 Sistem yang dijalankan membutuhkan koneksi internet yang stabil.  Fitur yang terdapat pada sistem antara lain: Feedstock, Products,

(11)

3.2 Work Breakdown Structure

Work Breakdown Structure (WBS) Dictionary. WBS

Code Element Name Definition

1 Memulai Proyek (I ni tiate the Project )

1.1 Definisikan Kebutuhan User ( Define User Requirements)

Pada tahap ini dilakukan analisa masalah, pendataan kebutuhan user, dan membuat sistem usulan

1.2 Membuat Project Plan ( Develop Project Plan)

Penulisan Project Plan oleh Project Manager

1.3 Persetujuan ( Approval ) Persetujuan dari pemilik proyek mengenai sistem usulan

2 Analisa Kebutuhan Sistem (System Requi r ements

Analysis )

2.1 Definisikan Kebutuhan Sistem ( Define System Requirements)

Mendefinisikan software dan hardware yang dibutuhkan Initiate the Project Define User Requiements Develop Project Plan Approval System Requirements Analysis Define System Requirement Define Features Create Use Case Diagram Create Activity Diagram Create Sequence DIagram Create Class Diagram System Design Create Mockup Database Design Create Prototype Implementation Create Database Develop System Integrate System Testing Maintenance Bug Fixing System Maintenance

Close the Project

Project Handover

Project Closing SISTEM INVENTARIS

(12)

2.2 Definisikan Fitur-fitur ( Define Features)

Mendefinisikan fitur apa saja yang akan dibuat

2.3 Membuat Use Case Diagram (Create Use Case Diagram)

Membuat use case diagram 2.4 Membuat Activity Diagram

(Create Activity Diagram)

Membuat activity diagram 2.5 Membuat Sequence Diagram

(Create Sequence Diagram)

Membuat sequence diagram 2.6 Membuat Class Diagram

(Create Class Diagram)

Membuat class diagram 3 Desain Sistem (System D esign )

3.1 Membuat Mockup Sistem (Create Mockup)

Pada tahap ini dilakukan pembuatan mockup sistem

menggunakan aplikasi desain 2D 3.2 Desain Database ( Database

Design)

Perancangan desain database menggunakan ERD

3.3 Membuat Prototype Desain Sistem (Create Prototype)

Membuat CSS, Javascript, berdasarkan mockup yang telah

dibuat sebelumnya 4 Implementasi

(I mplementati on )

4.1 Perancangan Database (Create Database)

Implementasi/pembuatan database berdasarkan desain database yang

telah dibuat 4.2 Pengembangan Sistem ( Develop

System/Coding )

Implementasi desain yang telah dibuat

4.3 Integrasi Sistem ( Integrate System)

Melakukan integrasi antar modul didalam sistem dan integrasi sistem dengan perangkat yang ada

4.4 Pengujian (Testing ) Melakukan pengujian terhadap sistem

5 Perawatan (Maintenance ) 5.1 Perbaikan Kesalahan Sistem

( Bug Fixing )

Melakukan perbaikan terhadap kesalahan sistem

5.2 Perawatan sistem (System Maintenance)

Melakukan perawatan secara berkala

6 Menutup Proyek (Cl ose the Project )

6.1 Serah terima proyek ( Project Handover )

Proyek yang telah selesai, ditandatangani dalam sebuah kontrak proyek

6.2 Penutupan proyek ( Project Closing )

(13)

4. Schedule/Time Management

4.1 Define Activities

Bagian ini mendefinisikan aktivitas apa saja yang akan terjadi dalam proses pengembangan proyek. Detail aktivitas ini dibuat berdasarkan Work Breakdown Structure. Proyek SISMF terdiri dari 6

aktivitas utama, diantaranya:

Kode WBS Aktivitas

1 Initiate the Project

2 System Requirement Analysis 3 System Design

4 Implementation 5 Maintenance 6 Close the Project

Dan berikut ini adalah detail aktivitasnya.

No Detail Aktivitas Kode

WBS Deskripsi 1 Definisikan Kebutuhan User ( Define User Requirements) 1.1  Analisa masalah  Membuat daftar kebutuhan user

 Membuat Sistem Usulan 2 Membuat Project Plan ( Develop Project Plan) 1.2  Penulisan dokumen project plan

 Analisa budget yang dibutuhkan

3

Persetujuan

( Approval ) 1.3

 Persetujuan terhadap project plan yang telah

dibuat sebelumnya 4 Definisikan Kebutuhan Sistem ( Define System Requirements) 2.1

 Membuat list kebutuhan sistem

 Analisa kebutuhan sistem 5

Definisikan Fitur-fitur ( Define

Features)

2.2  Membuat list fitur

6

Membuat Use Case Diagram (Create Use Case Diagram)

2.3  Membuat Use Case Diagram

(14)

7 Membuat Activity Diagram (Create Activity Diagram) 2.4  Membuat Activity Diagram 8 Membuat Sequence Diagram (Create Sequence Diagram) 2.5  Membuat Sequence Diagram 9 Membuat Class Diagram (Create Class Diagram)

2.6  Membuat Class Diagram

10 Membuat Mockup Sistem (Create Mockup) 3.1  Mendesain mockup sistem menggunakan aplikasi desain 2D 11 Desain Database ( Database Design) 3.2  Mendesain database menggunakan diagram-ER 12 Membuat Prototype Desain Sistem (Create Prototype) 3.3  Membuat prototype desain sistem  Analisa desain 13 Perancangan Database (Create Database) 4.1  Implementasi database  Integrasi database 14 Pengembangan Sistem ( Develop System/Coding ) 4.2  Merancang sistem (coding)  Analisa sistem 15 Integrasi Sistem

( Integrate System) 4.3  Integrasi modul sistem 16 Pengujian (Testing ) 4.4  Melakukan uji kelayakan

sistem 17 Perbaikan Kesalahan Sistem ( Bug Fixing ) 5.1  Memperbaiki kesalahan sistem 18 Perawatan sistem (System Maintenance) 5.2  Melakukan perawatan 19 Serah terima proyek ( Project Handover ) 6.1  Penyerahan proyek kepada project owner (PT. Sumber Makmur Food Tbk)

20 Penutupan proyek

(15)

4.2 Estimate Activity Duration

Berikut ini adalah estimasi waktu yang diperlukan untuk melaksanakan proyek berdasarkan aktivitas utama. Waktu pengerjaan tidak termasuk hari sabtu dan minggu.

Kode Aktivitas Duration (hari)

1 Initiate the Project 5

2 System Requirement Analysis 10

3 System Design 20

4 Implementation 30

5 Maintenance 10

6 Close the project 3

TOTAL 78

4.3 Project Schedule

Pembuatan jadwal proyek ( Project Schedule) dilakukan menggunakan MS. Project 2013. Berikut ini merupakan ringkasan timeline proyek (Gantt Chart terlampir).

Kode Aktivitas Minggu

ke-1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 Initiate the Project 2 System Requirement Analysis 3 System Design 4 Implementation 5 Maintenance 6 Close the project

5. Cost/Budget Management

Bagian ini akan menggambarkan estimasi biaya yang dibutuhkan dalam perancangan proyek.

(16)

Estimasi biaya didefinisikan dalam tabel-tabel berikut: No Jenis Barang Kuantitas Harga Total

1 PC Server 2 30.000.000 60.000.000 2 Routerboard 2 6.000.000 12.000.000 3 Main Switch 1 10.000.000 10.000.000 4 Modem ADSL 1 3.000.000 3.000.000 5 Switch 5 1.000.000 5.000.000 6 Printer 2 2.000.000 4.000.000 7 Scanner 1 2.500.000 2.500.000 8 Biaya pemasangan Internet 5.500.000 5.500.000 TOTAL 102.000.000

No Jenis Barang Kuantitas Harga Total 1 Lisensi Software 10 1.500.000 15.000.000 2 Window Server 2 5.000.000 10.000.000 TOTAL 25.000.000 Aktivitas Estimasi Waktu (Hari) Pelaku Jumlah Pelaku Tarif per-Staf Total Biaya (Rupiah)

Initiate the Project 5 PM 1 @750.000 3.750.000

DC 1 @550.000 2.750.000 System Requirements Analysis 10

PM 1 @750.000 7.500.000 AL 1 @550.000 5.500.000 SA 2 @500.000 10.000.000 System Design 20 PM 1 @750.000 15.000.000 DL 1 @550.000 11.000.000 SD 3 @500.000 30.000.000 Implementation Perancangan Sistem 25 PM 1 @750.000 18.750.000 DL 1 @550.000 13.750.000 PR 3 @500.000 37.500.000 Testing 5 DC 1 @300.000 1.500.000 PR 2 @300.000 3.000.000 Maintenance 10 PM 1 @250.000 2.500.000 PR 1 @250.000 2.500.000 DC 1 @250.000 2.500.000

Close the Project 3 PM 1 @400.000 1.200.000

DC 1 @300.000 900.000

(17)

6. Quality Management

6.1 Quality Planning

Quality planning diperlukan untuk mengidentifikasi standar kualitas yang dengan proyek yang sedang dikerjakan. Pendekatan manajemen mutu untuk proyek SISMF akan memastikan kualitas produk dan proses. Kualitas produk akan ditentukan dengan menggunakan ISO 9126. Sedangkan kualitas proses untuk proyek SISMF akan berfokus pada proses yang deliverable proyek. Menetapkan standar kualitas proses akan memastikan bahwa semua kegiatan sesuai dengan standar organisasi yang menghasilkan keberhasilan pengiriman produk.

Metrik akan dibentuk dan digunakan untuk mengukur kualitas di seluruh siklus hidup proyek untuk produk dan proses. Project Manager akan bertanggung jawab untuk bekerja dengan tim penjaminan kualitas untuk mendefinisikan metrik ini, melakukan pengukuran, dan menganalisa hasil.

6.2 Quality Assurance

Software quality assurance adalah kegiatan penting untuk setiap bisnis yang memproduksi produk yang akan digunakan oleh orang lain. Penjaminan kualitas dilakukan untuk mendefinisikan dan melakukan tindakan yang diperlukan untuk memastikan kualitas perangkat lunak.

6.3 Quality Control

Tindakan SQA dilakukan untuk mencapai satu set tujuan pragmatis (Pressman, 2010):

 Requirement Quality.

Kebenaran, kelengkapan, dan konsistensi dari model persyaratan (requirement model ) akan memiliki pengaruh yang kuat pada

(18)

kualitas semua produk kerja yang mengikuti. SQA harus memastikan bahwa tim perangkat lunak memiliki review model persyaratan untuk mencapai tingkat kualitas yang tinggi.

 Design Quality.

Setiap elemen dari model desain harus dinilai oleh tim perangkat lunak untuk memastikan bahwa hal itu menunjukkan kualitas ti nggi dan desain sendiri sesuai dengan persyaratan.

 Code Quality.

Source code dan produk kerja terkait (misalnya, informasi deskriptif lainnya) harus sesuai dengan standar lokal dan karakteristik exhibit yang akan memfasilitasi pemeliharaan.

 Quality Control Efectiveness.

Sebuah tim perangkat lunak harus memanfaatkan sumber daya yang terbatas yang memiliki kemungkinan tertinggi mencapai hasil berkualitas tinggi.

Berikut ini adalah metrik yang digunakan dalam melakukan penjaminan kualitas produk.

Goal Attribute Metric

Requirement Quality

Ambiguity Memeriksa apakah software memiliki penafsiran ganda

Completeness

Memeriksa kelengkapan fitur yang dibutuhkan apakah sudah sesuai dengan kebutuhan

Understandabiliy Memastikan bahwa sistem dapat dimengerti dengan mudah

Model Clarity Memeriksa model sistem yang dibuat (UML)

Traceability Sejumlah persyaratan tidak dapat dilacak untuk merancang /pengkodean Design

Quality

Component

Completeness Memeriksa kelengkapan desain sistem Interface

Complexity

Memeriksa konsistensi interface sistem

Code Quality Maintainability Memeriksa apakah sistem mudah untuk dilakukan perawatan

(19)

Reusability Presentase komponen yang dapat digunakan kembali Quality Control Effectiveness Resource

allocation Memeriksa jam kerja staf per aktivitas Testing

Effectiveness

Memeriksa jumlah kesalahan yang ditemukan dan melakukan tindakan untuk memperbaiki kesalahan

7. Human Resource Management

7.1 Job Description

Job Description untuk masing-masing posisi di dalam tim dijelaskan pada tabel di bawah ini.

Jabatan Job Description

Project Manager (PM) -Bertanggung jawab atas pelaksanaan proyek. -Mengkoordinasikan hal-hal yang berkaitan dengan proyek.

-Melakukan rapat dengan client untuk menentukan tujuan dan kebutuhan proyek. -Membuat dokumen Project Plan.

-Membuattimeline proyek.

-Membuat rencana pengalokasian sumber daya.

Analyst Leader (AL) -Bertanggung jawab atas pelaksaan proses analisa kebutuhan sistem.

-Mengawasi kinerja System Analyst. -Melakukan evaluasi kinerja.

System Analyst (SA) -Menganalisa kebutuhan sistem berdasarkan hasil identifikasi masalah.

-Mendefinisikan konten aplikasi

-Merancang model sistem menggunakan UML.

Developer Leader (DL) -Bertanggung jawab atas pelaksaan proses pengembangan sistem, baik dari proses desain

sistem maupun proses implementasi. -Merancang konsep sistem.

-Mengawasi kinerja Software Designer dan Programmer.

(20)

Software Designer (SD) -Mendesain antarmuka sistem (mockup). -Merancang interaksi sistem yang diperlukan. -Merancangdatabase yang diperlukan.

-Membuat prototypedesain sistem. Software

Developer/Programmer (PR)

-Implementasidatabase.

-Mengintegrasikan database dengan sistem. -Melakukan implementasi dari design yang telah dibuat.

-Melakukan perbaikan.

-Melakukan pengujian sistem.

Documentation (DC) -Mengumpulkan dokumen yang diperlukan. -Membuat dokumentasi sistem.

-Membuat buku petunjuk penggunaan sistem (user manual ).

-Melakukan pengujian.

-Mendokumentasikan setiap kesalahan sistem.

7.2 Internal Structure

Struktur internal organisasi yang mengelola proyek perancangan SISMF digambarkan pada bagan berikut.

7.3 Roles and Responsibility

Berikut ini adalah data staf yang terlibat dalam proyek perancangan SISMF beserta peranan dan posisinya.

Project Manager Analyst Team Leader System Analyst Developer Team Leader Software Designer Programmer Team Leader Tester Documentation

(21)

No Nama Peranan Posisi Email

1 Sarah Khairunnisa Project Manager PM sarah@gmail.com 2 Shanaz Virzi Anggota Tim DC shanaz@gmail.com 3 Petra Effendy Anggota Tim AL petra@gmail.com 4 Indah Purnama Anggota Tim SA indah@gmal.com 5 Feri Rahmanto Anggota Tim SA feri@gmail.com 6 Zayn Surya Anggota Tim DL zayn@gmail.com 7 Andi Pratama Anggota Tim PR andi@gmail.com 8 Rico Perdana Anggota Tim PR rico@gmail.com 9 Irsan Fahreza Anggota Tim PR irsan@gmail.com 10 Stanza Miranda Anggota Tim SD stanza@gmail.com 11 Edwin Widyanto Anggota Tim SD edwin@gmail.com 12 Dian Mahardika Anggota Tim SD dian@gmail.com

7.4 Staffing Plan

Tabel berikut ini menggambarkan jumlah staf yang dibutuhkan untuk pelaksanaan masing-masing aktivitas dalam proyek SISMF.

Aktivitas Jumlah Staf

Penanggung

jawab Pelaksana Initiate the Project 2 PM PM dan DC System Requirement

Analysis 3 PM AL dan SA (2)

System Design 4 PM DL dan SD (3)

Implementation 7 PM Implementasi: DL dan PR (3) Testing: DC, PR (2) Maintenance 3 PM DC dan PR

Close the Project 2 PM PM dan DC

TOTAL 22

Jumlah staf yang terlibat dalam proyek perancangan SISMF ini ada 12 orang. Sementara, jumlah staf yang dibutuhkan dalam pengerjaan keseluruhan proyek adalah 22 orang. Artinya, dalam hal

ini ada beberapa orang yang memiliki peran ganda atau satu orang melakukan 2-3 aktivitas yang berbeda.

(22)

aplikasi. Namun, project manager bekerja pada tahap inisiasi karena dalam tahapan tersebut ada proses pembuatan dokumen Project Plan. Hal ini disesuaikan dengan tugas seorang project manager untuk membuat dokumen Project Plan.

Pada tahap implementasi, resource dibagi menjadi 2 yaitu untuk proses implementasi dan testing. Implementasi meliputi proses pembuatan database dan pengembangan sistem/coding. Sementara testing dilakukan untuk menguji kelayakan sistem sebelum dikirimkan ke Project Owner atau pihak PT. Sumber Makmur Food Tbk. Tahapan implementasi memerlukan 4 orang staf. Dalam hal ini, yang bekerja pada tahapan implementasi adalah seorang developer leader (DL) dan 3 orang programmer. Kemudian untuk proses testing, dilakukan oleh seorang documentation (DC) dan 2 orang programmer (PR).

Tahap maintenance dilakukan oleh seorang documentation (DC) dan seorang programmer (PR). Documentation bertindak sebagai pihak yang mendokumentasikan segala macam kesalahan sistem yang

terjadi setelah sistem dibuat. Sedangkan programmer bertindak sebagai teknisi yang bertugas melakukan perbaikan kesalahan sistem.

Kemudian untuk tahapan akhir, Close the Project dilakukan oleh project manager (PM) dan documentation (DC). Project Manager bertugas mempresentasikan hasil akhir proyek dan menandatangani surat kontrak tanda proyek telah diselesaikan. Sementara, documentation bertugas menyimpan semua dokumentasi pengerjaan proyek dari awal hingga akhir. Selain itu, documentation juga

(23)

8. Communication Management

8.1 Communication Plan

 External Communication

Bentuk komunikasi eksternal yang digunakan antara lain: laporan status proyek untuk mengetahui perkembangan pelaksanaan proyek SISMF, rapat koordinasi stakeholder, pembuatan memo dan review laporan bulanan. Rapat dilakukan sesuai dengan jadwal yang telah ditentukan. Apabila ada hal-hal mendesak, dapat disesuaikan dengan jadwal yang telah dibuat.

 Internal Communication

Bentuk komunikasi internal yang digunakan antara lain: formal dan informal, tertulis dan tidak tertulis, dan komunikasi vertikal dan horizontal. Komunikasi formal yang dimaksud adalah komunikasi yang dilakukan dengan meeting (rapat), sementara informal yaitu komunikasi yang dilakukan melalui media teknologi seperti email atau telepon. Komunikasi tertulis berupa hasil rapat yang tertulis baik dalam bentuk softcopy

maupun hardcopy, sedangkan komunikasi tidak tertulis berupa komunikasi yang dilakukan secara langsung dengan tatap muka antara kedua pihak. Komunikasi vertikal artinya komunikasi dilakukan antara project manager dengan anggota timnya atau project manager dengan pemilik proyek (Project Owner) dan komunikasi horizontal merupakan komunikasi koordinasi seperti antara project manager dengan IT support.

8.2 Manage Communication

Manage Communication merupakan proses untuk membuat, mengumpulkan, mendistribusikan, dan menyimpan informasi sebuah proyek. Distribusi informasi dapat berupa softcopy maupun hardcopy.

(24)

Informasi yang dikumpulkan adalah hasil rapat yang dilakukan antara stakeholder. Berikut ini adalah gambaran kebutuhan komunikasi untuk menjalankan proyek SISMF.

Communication Type

Objective of

Communication Medium Frequency Audience Owner Deliverable Format Mendefinisikan kebutuhan Menentukan sistem usulan sesuai kebutuhan user Meeting 1 kali Project Owner, Project Team Project

Manager Approval Softcopy

Rapat Tim Mengetahui perkembangan proyek Meeting 1 kali dalam seminggu Project Team Project Manager Agenda, Jadwal proyek Softcopy dan hardcopy Laporan rutin Melaporkan perkembangan pelaksanaan proyek Meeting 1 kali dalam seminggu Project Owner, Project Team Project Manager Report Softcopy dan hardcopy Rapat tim analis Pengumpulan

data Meeting 1 kali

System Analyst Analyst Leader Evaluasi sistem yang ada Softcopy Persetujuan Menyetujui

hasil analisis Meeting 1 kali

Analyst Team

Project

Manager Approval Softcopy Rapat tim

developer

Perancangan

proyek Meeting 1 kali

Developer Team Developer Leader Pembuatan proyek Softcopy Membahas fitur Menjelaskan fitur yang ada pada sistem Meeting 1 kali dalam seminggu Programmer Project

Manager Daftar fitur Softcopy Membahas interface Membangun interface sesuai dengan kebutuhan Meeting 1 kali dalam seminggu Software Designer Project

Manager Mockup Softcopy

Persetujuan

Menyetujui hasil rancangan proyek

Meeting 1 kali Developer Team

Project

Manager Approval Softcopy

Pengadaan perangkat keras Pembahasan mengenai pengadaan dan instalasi hardware Email or phone 1 kali dalam seminggu IT Support Project

Manager Instalasi Softcopy

Pengujian

Melakukan pengujian

terhadap sistem

Meeting 1 kali Tester Team Project

Manager Approval Softcopy Penyerahan

sistem Closing project Meeting 1 kali

Project Owner Project Manager Project Signature Softcopy dan hardcopy

(25)

9. Risk Management Plan

9.1 Plan Risk Management

Bagian ini akan menjelaskan mengenai kategori resiko yang mungkin terjadi. Pendekatan untuk menentukan kategori resiko menggunakan Risk Breakdown Structure (RBS).

Risk Breakdown Structure

9.2 Identify Risk

Bagian ini akan mengidentifikasi resiko apa saja yang mungkin terjadi, menentukan ukuran peluang terjadinya resiko dan dampak yang ditimbulkannya, serta menentukan respon yang mungkin

Technical Hardware Requirement Operating System Design Interface Changes Performances Quality Security Human Resource Unreliability of Human Resource Fraud Human Resource Resign External Weather Disaster Unexpected Event Project Management Estimating Planning Communica tion Controlling SISTEM INVENTARIS

(26)

diberikan untuk menyelesaikan suatu masalah/resiko yang terjadi. Output  Risk Register

Peluang terjadinya resiko ( Probability) dan dampak yang ditimbulkan ( Impact ) menggunakan skala sebagai berikut :

Level Skala Kode

1 Very Low VL 2 Low L 3 Medium M 4 High H 5 Very High VH Risk Register

No Risk Risk Trigger Probability Impact Responsibility Response

1 Hardware Requirement Spesifikasi hardware untuk server tidak sesuai dengan kebutuhan L H PM Ganti atau kurangi kebutuhan hardware 2 Operating System Sistem operasi belum terinstall L H PM Melakukan instalasi sistem operasi 3 Design Interface Changes Permintaan dari client M H PM, SD Mengganti desain sistem

4 Performance Koneksi internet

tidak stabil M H PM, Teknisi

Analisis masalah, Melakukan manajemen bandwidth 5 Quality Banyak fitur yang tidak berfungsi sesuai dengan tujuan proyek M H PR Memperbaiki kesalahan

(27)

6 Security Sistem diserang hacker yang menyebabkan server down H VH PR Programmer memperbaiki sistem, dan meningkatkan keamanan sistem 7 Unreliability Human Resource Kegagalan staff dalam menyelesaikan pekerjaan L M PM Melakukan proses seleksi, Mengadakan pelatihan, dan Komunikasi antartim 8 Fraud Staff melakukan tindakan pengelabuan terhadap keuangan maupun kinerja L M PM Melakukan proses seleksi yang ketat 9 Human Resource Resign Konflik L M PM Mengganti staff 10 Weather - L M PM -11 Disaster - L M PM -12 Unexpected Event Kejadian tak terduga seperti : kebakaran, mati listrik L M PM Memindahkan resiko pada pihak ketiga 13 Estimating Estimasi biaya dan waktu tidak realistis L M PM, SA Membuat beberapa estimasi 14 Planning Pengembangann ya terlalu sulit secara teknis L M PM Analisis teknis, Melatih dan mengembangk an staff Sistem tidak selesai sesuai jadwal M H PM Melakukan penambahan staff, Membuat schedule task 15 Communicat ion Miss komunikasi L M PM Komunikasi secara rutin 16 Controlling - L M PM Melakukan control secara rutin

(28)

9.3 Qualitative Risk Analysis

Pada bagian sebelumnya, telah dijabarkan mengenai skala pengukuran untuk probability dan impact . Resiko dapat diprioritaskan untuk analisis kuantitatif dan perencanaan tindakan berdasarkan rating resiko tersebut. Maksudnya setiap resiko memiliki skor tersendiri yang akan menentukan apakah resiko tersebut harus segara ditangani atau bisa diabaikan apabila resiko tersebut dianggap ti dak penting.

SKOR SKALA DESKRIPSI 1-2 Very Low Resiko ini bisa diabaikan

3-4 Low Pihak manajemen proyek harus melakukan tindakan pencegahan 5-10 Medium Evaluasi sistem secara periodik 11-17 High Butuh perhatian segera

18-25 Very High Penanganan secepatnya

IMPACT 1 Very Low 2 Low 3 Medium 4 High 5 Very High 1 Very Low 1 2 3 4 5 2 Low 2 4 6 8 10 3 Medium 3 6 9 12 15 4 High 4 8 12 16 20 5 Very High 5 10 15 20 25

Berdasarkan tabel Risk Register, resiko yang paling membutuhkan penanganan secepatnya dengan skala Very High yaitu Security. Karena aspek keamanan merupakan yang terpenting dalam pembuatan sistem dengan database yang cukup banyak dan kompleks.

P R O B A B I L I T Y

(29)

Apabila aspek keamanan ini tidak ditindaklanjuti dengan cepat, maka akan berakibat fatal dan bisa menyebabkan server down.

Sementara itu resiko yang memiliki skala high seperti Design Interface Changes, Performances, Quality, dan Planning membutuhkan perhatian segera. Artinya, keempat aspek ini penting dan harus dilakukan respon atau dikomunikasikan terlebih dahulu dengan pihak perusahaan.

9.4 Quantitative Risk Analysis

Bagian ini akan menjelaskan analisis kuantitatif dari dampak yang akan terjadi.

Gambar 1 Skala dampak resiko pada tujuan utama proyek Sumber: PMBOK Fifth Edition, 2013

Elemen WBS Very Low Low Medium High Very High Initiate the Project Insignificant cost increase 325.000 650.000 1.300.000 2.600.000 System Requirement Analysis Insignificant cost increase 1.150.000 2.300.000 4.600.000 9.200.000

(30)

System Design Insignificant cost increase 2.800.000 5.600.000 11.200.000 22.400.000 Implementation Insignificant cost increase 3.725.000 7.450.000 14.900.000 29.800.000 Maintenance Insignificant cost increase 2.000.000 4.000.000 8.000.000 16.000.000 Close the project Insignificant cost increase 105.000 210.000 420.000 840.000

Analisis tersebut dilakukan berdasarkan estimasi biaya yang dibutuhkan dalam setiap tahapan pekerjaan proyek. Biaya diatas merupakan kerugian yang akan dialami oleh perusahaan apabila proyek ini mengalami kendala yang ada pada tahapan-tahapan tersebut sehingga membuat proyek mengalami delay dan membutuhkan biaya tambahan.

9.5 Plan Risk Response

Jika terjadi masalah, maka ada 4 strategi yang mungkin dilakukan (PMBOK, 2013) yaitu:

 Avoid : Menghindari resiko. Dilakukan oleh tim proyek

dengan mengeliminasi ancaman atau menjaga proyek dari dampak yang ditimbulkan. Beberapa resiko yang muncul pada awal pembuatan proyek dapat dihindari dengan melakukan klarifikasi requirement, memperoleh informasi, meningkatkan komunikasi atau meminta pendapat para ahli (expertise).

 Transfer : Memindahkan resiko. Tim proyek menggeser

dampak atau ancaman kepada pihak ketiga. Transfer resiko ini berarti meminta pihak ketiga untuk menanggung resiko

tersebut. Contonya : dengan menggunakan jasa asuransi.

 Mitigate : Mitigasi. Tindakan mengurangi resiko sampai ke

(31)

untuk mengurangi dampak resiko. Karena hal tersebut biasanya lebih efektif dibandingkan mencoba memperbaiki

kerusakan setelah resiko terjadi.

 Accept : Penerimaan. Strategi ini bisa digunakan untuk

resiko atau ancaman yang bersifat negatif namun tidak memiliki dampak yang berarti. Dalam strategi ini, resiko diterima oleh tim proyek dan tidak mengambil tindakan apapun untuk mengurangi dampak resiko.

No Risk Response Strategy

1 _{Hardware Requirement} Ganti atau kurangi kebutuhan

hardware Avoid 2 _{Operating System} _{Melakukan instalasi sistem operasi} Mitigate 3 Design Interface

Changes Mengganti desain sistem Mitigate 4 _Performance Analisis masalah, Melakukan

manajemen bandwidth Mitigate 5 _Quality _{Memperbaiki kesalahan} Avoid 6 _Security Programmer memperbaiki sistem,

dan meningkatkan keamanan sistem Avoid 7 Unreliability Human

Resource

Melakukan proses seleksi, Mengadakan pelatihan, dan Komunikasi antartim

Mitigate

8 _Fraud Melakukan proses seleksi yang

ketat Mitigate 9 _{Human Resource Resign} _{Mengganti staff} Mitigate

10 _Weather _- Transfer

11 _Disaster _- Transfer 12 _{Unexpected Event} Memindahkan resiko pada pihak

ketiga Transfer 13 _Estimating _{Membuat beberapa estimasi} Avoid 14 _Planning Analisis teknis, Melatih dan

mengembangkan staff Mitigate Melakukan penambahan staff Mitigate 15 _{Communication} _{Komunikasi secara rutin} Avoid 16 _Controlling _{Melakukan control secara rutin} Avoid