bab 3 analisis sistem berjalan 3.1 gambaran umum ...thesis.binus.ac.id/doc/bab3/2012-1-00097-bab...

29

BAB 3

ANALISIS SISTEM BERJALAN

3.1 Gambaran Umum Perusahaan

Gambaran umum PT WOM Finance, Tbk. adalah sebagai berikut:

3.1.1 Sejarah Perusahaan

PT Wahana Ottomitra Multiartha, Tbk. (WOM Finance) sebagai

perusahaan pembiayaan sepeda motor yang terkemuka di Indonesia, memiliki

sejarah yang cukup panjang. Perusahaan pernah beberapa kali berganti nama.

Semula adalah PT Jakarta Tokyo Leasing yang berdiri tahun 1982. Kemudian

di tahun 1997, menjadi PT Wahana Ometraco Multiartha yang diakuisisi oleh

PT Fuji Semeru Leasing. Mulai tahun 2000, Perusahaan bertransformasi

menjadi WOM Finance serta menyediakan pembiayaan untuk sepeda motor

baru dan bekas khususnya merk Honda, Yamaha dan Suzuki.

Tahun 2003, perusahaan memasuki pasar modal dengan menerbitkan

Obligasi I senilai Rp 300 miliar. Tahun 2004, WOM Finance menjadi

perusahaan publik melalui Penawaran Umum Saham Perdana dan pencatatan

saham di Bursa Efek Jakarta dan Bursa Efek Surabaya. Setahun kemudian, PT

Bank Internasional Indonesia, Tbk. (BII) dan konsorsiumnya, International

Finance Corporation (IFC) dan DBS nominees Pte. Ltd., menjadi mitra

strategis dengan mengakuisisi 67% saham perusahaan. Kemudian WOM

Finance menerbitkan Obligasi II senilai Rp 500 miliar. Tahun 2006, WOM

Finance menerbitkan Obligasi III senilai Rp. 825 miliar. Karena kinerjanya

yang cemerlang, WOM Finance memperoleh berbagai penghargaan bergengsi

30

antara lain Multifinance Awards 2006 oleh Majalah Infobank dan

Multifinance Awards 2007 oleh Majalah Investor. Obligasi IV senilai Rp 1

triliun kemudian diterbitkan kembali oleh WOM Finance pada tahun 2007. Di

tahun yang sama, perusahaan menduduki peringkat ketiga terbesar perusahaan

pembiayaan sepeda motor dengan total asset Rp 4,8 triliun.

Sebagai perusahaan yang adaptif, fleksibel dan peka terhadap kebutuhan

masyarakat, WOM Finance memperkenalkan semboyan baru, “Wujudkan

Impian Menyentuh Hati”. Lebih dari sekedar mitra kredit yang strategis –

WOM Finance membantu mewujudkan impian masyarakat Indonesia untuk

memiliki sepeda motor apapun pilihan merek dan jenisnya. Selain pemekaran

jaringan penjualan, pada akhir tahun 2008 WOM Finance telah melakukan

konsolidasi internal dan penyempurnaan kebijakan dalam manajemen resiko.

Dengan pemilihan portofolio yang tepat, WOM Finance mampu

meningkatkan profit dan mengarahkan bisnisnya ke arah yang lebih baik dan

sehat. WOM Finance telah membukukan lebih dari 1 juta pelanggan serta

senantiasa memudahkan pelayanan dan meningkatkan kepuasan kepada para

konsumen. Hal ini dicanangkan dengan program PeSAT (Pelayanan cepat,

Syarat mudah, Aman dan Terpercaya). WOM Finance kini menuju layanan

one day service dengan selalu memperbarui dan mempersiapkan infrastruktur

yang tepat khususnya di bidang teknologi informasi.

3.1.2 Visi dan Misi PT.WOM Finance

Visi PT.WOM Finance adalah menjadi salah satu perusahaan pembiayaan

konsumen terbaik di Indonesia dengan menerapkan tata kelola perusahaan.

31

Misi PT.WOM Finance adalah mengutamakan kepuasan pelanggan dan

mitra kerja lainnya, membangun infrastruktur berbasis IT untuk melaksanakan

proses yang baik, mengembangkan dan memperluas jaringan usaha, terutama

di daerah potensial, dan mengoptimalkan kinerja perusahaan.

3.1.3 Struktur Organisasi PT.WOM Finance

Struktur adalah skema atau bagan mengenai sistem organisasi suatu

usaha, lembaga atau organisasi lainnya. Struktur organisasi ini

menggambarkan tata hubungan kerja dalam organisasi, baik tata hubungan

kerja wewenang (hirarki) ataupun tata hubungan kerja tiap-tiap fungsi yang

ada dan yang tercakup dalam seluruh operasi (kegiatan) badan usaha, lembaga

atau organisasi tersebut.

Suatu organisasi akan menjadi alat yang efektif bagi manajemen dalam

mencapai tujuannya apabila dalam organisasi tersebut terdapat kesatuan

tujuan, pembagian wewenang dan tanggung jawab yang tegas serta hubungan

kerja sama yang terkoordinir. Terkoordinir dalam arti setiap tindakan yang

dikelola oleh masing-masing komponen organisasi harus sesuai dengan yang

lainnya.

Untuk dapat memenuhi syarat adanya suatu pengendalian internal yang

baik, hendaknya struktur organisasi dapat memperlihatkan adanya pemisahan

fungsi-fungsi operasional, penyimpangan dan pencatatan, dengan maksud

agar dapat mencegah timbulnya kecurangan-kecurangan dalam perusahaan.

Struktur organisasi divisi IT PT.WOM Finance dapat dilihat pada

halaman berikut:

32

Gambar 3.1 Struktur Organisasi Divisi IT PT Wom Finance, Tbk.

33

3.1.4 Pembagian Tugas dan Wewenang

Untuk mencapai visi dan misi perusahaan, setiap bagian memiliki tugas

dan wewenang spesifik dalam mengelola perusahaan. Berikut rincian

pembagian tugas dan wewenang pada divisi IT PT.WOM Finance:

a. Unit Kerja (Product Owner)

Unit Kerja (Product Owner) memiliki tugas dan wewenang sebagai

berikut:

1) Mengajukan / memberitahukan kepada IT PMO mengenai inisiatif

sebuah permintaan (change request) menyangkut pengembangan

aplikasi bisnis.

2) Berdiskusi dengan Solution Delivery Division Head dan Business

Analyst serta Development untuk menganalisis secara lebih detail

mengenai permintaan tersebut sesuai dengan kebutuhan bisnis dan

menentukan prioritasnya yang disesuaikan dengan daftar proyek

yang sudah dimiliki oleh Unit Kerja tersebut.

3) Membuat CR berdasarkan hasil diskusi dengan melampirkan BRD

(Business Requirement Document) / FSD (Functional Specification

Document) dan memberikannya kepada IT PMO.

4) Formulir CR tersebut harus disetujui oleh Atasan Langsung /

Supervisor pemohon dan Project Sponsor (level Direksi/ BOD).

5) Menetapkan koordinator user dalam pelaksanaan UAT.

6) Bekerja sama dengan UAT unit dan Solution Delivery dalam

membuat UAT plan.

34

7) Melaksanakan UAT sesuai dengan UAT script dan jadwal yang

ditetapkan dalam UAT plan.

8) Mencatat semua kejadian dan masalah-masalah yang timbul pada

saat pelaksanaan UAT dalam dokumen UAT.

9) Memberi persetujuan/ penolakan atas hasil UAT.

b. IT PMO

IT PMO memiliki tugas dan wewenang sebagai berikut:

1) Memastikan bahwa formulir CR telah diisi dengan benar dan

lengkap.

2) Melakukan registrasi / pencatatan CR yang masuk serta No. CR.

3) Mempersiapkan pertemuan dengan team Business Analyst dan

Development serta Solution Delivery Head untuk berdiskusi

membahas CR baru yang dilakukan 2 kali seminggu.

4) Mencatat semua informasi ke dalam daftar Log CR, termasuk

informasi mengenai selesainya pelaksanaan proyek.

5) Menginformasikan CR (beserta nomor CR) kepada Unit Kerja dan

Business Analyst dan System Analyst terkait.

6) Memberikan sebuah copy CR tesebut kepada Unit Kerja dan Business

Analyst dan System Analyst terkait, agar Unit Kerja terkait berhak dan

dapat mengingatkan serta menanyakan status perkembangan CR

tersebut.

7) Mencatat hasil evaluasi dan informasi jadwal proyek dari Business

Analyst dan System Analyst ke dalam daftar Log CR.

35

8) Menginformasikan hasil evaluasi dan jadwal pelaksanaan CR kepada

Unit Kerja.

9) Melakukan follow-up terhadap CR dan memonitor pelaksanaan

proyek sampai selesai.

10) Secara periodik menginformasikan pelaksanaan proyek kepada Unit

Kerja dan manajemen (termasuk isu-isu yang muncul).

c. Solution Delivery Division Head

Solution Delivery Division Head memiliki tugas dan wewenang sebagai

berikut:

1) Menganalisis permintaan Unit Kerja atau berdiskusi dengan Unit

Kerja dan Business Analyst serta Development untuk mengklarifikasi

inisiatif permintaan pengembangan aplikasi agar sesuai dengan

kebutuhan bisnis dan menentukan prioritas proyek yang disesuaikan

dengan daftar proyek yang sudah dimiliki oleh Unit Kerja tersebut.

2) Memberi sign-off pada CR form dan memberikan komentar / usulan.

3) Menugaskan petugas atau tim-tim terkait untuk menyelesaikan CR

tersebut.

d. Business Analyst dan System Analyst

Business Analyst dan System Analyst memiliki tugas dan wewenang

sebagai berikut:

36

1) Berdiskusi dengan Unit Kerja dan Solution Delivery Division Head

untuk mengklarifikasi dan menganalisis inisiatif permintaan

pengembangan aplikasi agar sesuai dengan kebutuhan bisnis.

2) Mengevaluasi CR untuk menentukan skala pekerjaan dan jadwal

pelaksanaan proyek. Business Analyst dan System Analyst memiliki

waktu 5 hari kerja (max 1 minggu) untuk mengevaluasi CR.

3) Menyampaikan hasil evaluasi CR kepada Solution Delivery Division

Head beserta informasi jadwal pelaksanaan dan waktu yang

dibutuhkan untuk menyelesaikan CR.

4) Menyampaikan / memberikan update status proyek kepada IT PMO.

5) Pada phase UAT, membuat dan melakukan UAT script yang

dibuktikan dengan dokumen SIT.

6) Menyerahkan program aplikasi yang telah dibuat dan dokumen SIT

ke UAT unit.

e. UAT Unit

UAT Unit memiliki tugas dan wewenang sebagai berikut:

1) Menerima program aplikasi dan dokumen SIT dari Solution Delivery.

2) Membuat UAT Plan (termasuk UAT script dan UAT approach)

bekerja sama dengan Solution Delivery dan user.

3) Menunjuk UAT Coordinator untuk program aplikasi yang akan dites.

4) Berperan aktif dalam pelaksanaan UAT, seperti menyiapkan data dan

infrastruktur agar pelaksanaan UAT dapat berhasil dengan baik,

37

memastikan bahwa semua skenario dalam UAT script dites serta

mencatat kejadian-kejadian selama UAT berlangsung.

5) Mengembalikan program aplikasi dan dokumen UAT ke Solution

Delivery untuk perbaikan jika UAT tidak berhasil.

6) Menyerahkan program aplikasi dan dokumen UAT ke Service

Delivery untuk pembuatan PCR jika UAT berhasil.

3.2 Analisis Permasalahan

Berikut ini adalah analisis permasalahan yang terjadi terkait Change Request

Management:

3.2.1 Analisis Proses Bisnis yang Sedang Berjalan

Proses bisnis yang sedang berjalan dapat dilihat dalam bentuk use case

berikut:

38

Gambar 3.2 Use Case Proses Bisnis Yang Sedang Berjalan

39

Proses bisnis yang berjalan ini berawal dari unit kerja mengajukan form

CR ke IT PMO dan unit kerja harus menjelaskan mengenai kebutuhan

penambahan atau perubahan tersebut, manfaat, tingkat kepentingan (prioritas)

dan kapan dibutuhkan untuk dipakai. Prioritas terdiri dari 4 kategori sebagai

berikut:

a. Prioritas rendah, diberikan untuk CR yang harus dimulai dalam 30 hari

kerja.

b. Prioritas sedang, diberikan untuk CR yang harus dimulai dalam 20 hari

kerja.

c. Prioritas tinggi, diberikan untuk CR yang harus dimulai dalam 10 hari

kerja.

d. Prioritas sangat mendesak, diberikan untuk CR yang harus dimulai dalam

5 hari kerja.

Kemudian IT PMO memeriksa kelengkapan pengisian dokumen CR

serta kelengkapan dokumen lampiran lainnya apabila ada atau diperlukan. Jika

semua dokumen lengkap maka IT PMO akan memberikan nomor registrasi.

Jika permintaan CR tersebut sangat mendesak maka IT PMO wajib segera

melaporkan ke Solution Delivery Division Head.

Solution Delivery Division Head berhak menentukan prioritas

penyelesaian CR tersebut. Solution Delivery Division Head juga akan

menugaskan siapa yang harus mengerjakan CR tersebut dengan pertimbangan

kesibukan masing-masing petugas. Skala prioritas penyelesaian CR ditentukan

oleh BOD apabila diperlukan eskalasi, tetapi apabila cakupan masih dalam

skala kecil maka cukup sampai persetujuan Chief IT dan Solution Delivery

40

Division Head. Business Analyst dan Developer akan memberikan konfirmasi

mengenai kesanggupan penyelesaian CR tersebut. Assessment tersebut harus

diinformasikan ke Solution Delivery Division Head. Setelah para petugas telah

ditunjuk dan Solution Delivery Division Head mendapatkan hasil evaluasi CR

tersebut maka Solution Delivery Head Division memberikan tugas untuk IT

PMO mendokumentasikan CR yang akan diproses atau ditolak tersebut ke

dalam Log CR (berbentuk file Ms. Excel).

IT PMO diwajibkan menginformasikan status CR tersebut kepada

user/unit kerja, apakah bisa dilanjutkan, ditunda atau ditolak. IT PMO

memberikan sebuah salinan dari dokumen CR yang disetujui ataupun yang

ditolak kepada user / unit kerja. Jika perlu ada perubahan isian form CR maka

user / unit kerja diwajibkan merevisi form CR tersebut dan

mengembalikannya berikut lampiran apabila diperlukan (seperti paraf

persetujuan dan sebagainya). Pengembalian bisa dilakukan langsung ke IT

PMO.

IT PMO harus mengikuti perkembangan setiap CR dan berhak

menanyakan status CR kepada petugas yang ditunjuk. IT PMO harus

memberikan update status CR-CR yang sedang dikerjakan oleh petugas yang

ditunjuk setiap minggu dan setiap bulan kepada Solution Delivery Division

Head. Dalam 2x seminggu, IT PMO akan melaporkan dan mendiskusikan

dengan Solution Delivery Division Head mengenai CR baru berserta team

Business Analyst dan Developer. IT PMO diwajibkan pula memberikan

informasi kepada user/unit kerja mengenai status CR yang sedang berjalan. IT

PMO diwajibkan mengkoordinir jika diperlukan untuk tes CR bersama

41

dengan user/unit kerja. IT PMO setiap akhir bulan mengkoordinir meeting

dengan perwakilan setiap direktorat untuk melaporkan update status CR.

Berikut ini adalah macam-macam status CR:

a. OPEN, merupakan status default CR saat pertama kali di-input. CR

dengan status OPEN dan telah mendapat persetujuan dari Project

Manager, Solution Delivery Division Head dan Chief IT serta telah

memiliki Business Analyst dan System Analyst yang bertanggung jawab

dalam pengerjaan dapat diubah statusnya menjadi ASSIGNED.

b. ASSIGNED, merupakan status CR dimana CR tersebut baru akan mulai

dikerjakan oleh Business Analyst. Untuk memulai pengerjaan CR, status

ASSIGNED harus diubah menjadi IN PROGRESS.

c. IN PROGRESS, merupakan status CR ketika berada dalam tahap

pengerjaan oleh Business Analyst dan System Analyst. Di dalam status IN

PROGRESS, terdapat 4 fase yaitu FSD (Functional Spesification

Document), DEV (Development), SIT (System Integration Testing), dan

UAT (User Acceptance Test). Setelah fase UAT diselesaikan, status CR

berubah menjadi DONE.

d. DONE, merupakan status CR yang telah selesai dikerjakan oleh BA dan

SA. CR dengan status ini dapat diubah menjadi READY TO DEPLOY.

e. READY TO DEPLOY, merupakan status CR yang telah siap

diimplementasikan ke sistem yang sebenarnya. CR dengan status inilah

yang diproses dalam PCR (Production Change Request).

f. CLOSED, merupakan status CR setelah CR tersebut masuk ke tahap PCR.

42

g. PENDING, merupakan status CR yang ditunda pengerjaannya karena

berbagai faktor, misalnya prioritas yang rendah dibanding CR lain yang

baru masuk dengan prioritas lebih tinggi. CR dengan status PENDING

bisa dimulai kembali dengan pengubahan status menjadi OPEN.

3.2.2 Permasalahan yang Dihadapi

Berdasarkan proses bisnis yang berjalan dapat diketahui permasalahan

sebagai berikut:

a. Dokumentasi CR secara manual menyulitkan project manager untuk

melaporkan update status CR.

b. Project manager kesulitan dalam tracking waktu pengerjaan sebuah

change request.

c. Belum ada bentuk laporan / report khusus untuk project manager dalam

pengelolaan pengerjaan CR.

3.3 Analisis Wawancara

Berdasarkan proses bisnis berjalan pada perusahaan, maka diperlukan verifikasi

dengan Project Manager serta semua Business Analyst dan System Analyst

menggunakan analisis wawancara yang terdiri dari sejumlah pertanyaan agar dapat

menemukan solusi terbaik.

Berikut ini adalah rangkuman hasil wawancara untuk masing-masing jenis

pengguna:

43

Tabel 3.1 Hasil wawancara dengan project manager

Nama: Bayu Isnandar

Jabatan: IT PM (Project Manager)

Tanggal Wawancara: 16 Oct 2011

Jam Wawancara: 14.00

Tempat: WOM Finance

Daftar Pertanyaan:

1. Seberapa tingkat keefektifan sistem pendataan Change Request yang

sudah berjalan saat ini dari segi waktu dan akurasi data?

Belum efektif. Masih banyak data yang belum teridentifikasi antara data

yang sudah selesai maupun yang sedang berjalan. Pembuatan laporan

masih dilakukan secara manual, penugasan BA dan SA juga dilakukan

secara manual. Selain itu, terjadi kesulitan tracking waktu antara waktu

input, analisa data maupun yang sudah diimplementasi. Data yang di-

input rawan kesalahan dan membutuhkan waktu yang lama untuk

memroses data.

Alasan pertanyaan: Agar dapat mengetahui seberapa efektif sistem yang

sudah berjalan.

2. Kendala apa saja yang dihadapi selama menggunakan sistem pendataan

Change Request saat ini?

• Tidak bisa menganalisa waktu yang dihabiskan untuk proses analisa

CR sebelum masuk pengerjaan.

• Pembuatan report masih manual.

• Penugasan CR masih dilakukan secara manual.

• Tidak ada sinkronisasi dengan PCR (Production Change Request).

Alasan pertanyaan: Agar dapat mengetahui kendala yang muncul pada

sistem lama agar dapat ditanggulangi untuk ke depannya.

3. Perubahan apa saja yang diharapkan dari pembuatan website pendataan

dan monitoring proyek Change Request ini?

Bisa mempermudah tracking waktu pengerjaan CR dan pembuatan

44

laporan.

Alasan pertanyaan: Agar dapat mengetahui apa saja yang diharapkan

pengguna setelah menggunakan website yang dibuat untuk pendataan dan

monitoring proyek Change Request.

4. Fitur / modul apa saja yang diperlukan pengguna dalam website ini?

• Ada laporan workflow (yang menunjukkan waktu analisis CR

sebelum dikerjakan oleh BA dan SA).

• Ada fitur penghasil report otomatis.

• Penugasan CR secara otomatis.

• Sinkronisasi dengan PCR.

• Ada auto-mail sebagai reminder untuk penugasan maupun perubahan

status CR.

• Ada fitur export report dalam bentuk Excel, PDF dan HTML.

Alasan pertanyaan: Untuk mengetahui fitur / modul apa saja yang

diperlukan dalam website ini.

Tabel 3.2 Hasil wawancara dengan business analyst

Kelompok pengguna: BA (Business Analyst)

Daftar Pertanyaan:



Sulit mencari data CR yang lama yang sudah didata untuk dianalisa lagi.


sudah berjalan.



Susah membaca tulisan pada form CR yang diajukan oleh Unit Kerja.



45



Pengerjaan CR menjadi lebih efisien dan optimal.





• Bisa melihat data CR yang sudah diinput.

• Ada reminder untuk pengerjaan CR agar tidak delay.



Tabel 3.3 Hasil wawancara dengan system analyst

Kelompok Pengguna: SA (System Analyst)

Daftar Pertanyaan:



Semua aksi dilakukan secara manual sehingga menghabiskan waktu.


sudah berjalan.



Sulit sinkronisasi CR dengan PCR. Update status CR yang masuk PCR

harus dilaporkan secara manual ke PM.





46

Mempermudah pembuatan PCR.





• Sinkronisasi CR dengan PCR

• Fitur print PCR form berdasarkan CR mana saja yang sudah selesai.



Dari wawancara di atas dapat disimpulkan sebagai berikut:

Tabel 3.1 Hasil Analisis Permasalahan Berdasarkan Wawancara

No. Permasalahan

Yang Muncul

Target Pengguna

Yang Mengalami

Permasalahan

Evaluasi

1. Proses peng-

input-an data

CR

Project Manager Pertanyaan: seberapa tingkat

keefektifan sistem pendataan Change

Request yang sudah berjalan saat ini

dari segi waktu dan akurasi data?

Membutuhkan waktu lebih dan data

tidak bisa dijamin keakuratannya

karena tidak dibakukan ke dalam

format khusus.

Analisa: sistem yang lama rawan

kesalahan dan memboroskan waktu.

2. Kendala

dalam sistem

lama (sistem

manual)

Project Manager,

Business Analyst,

System Analyst

Pertanyaan: kendala apa saja yang

dihadapi selama menggunakan

sistem pendataan Change Request

saat ini?

Sulit memroses pengerjaan CR

47

secara manual, sulit membuat

laporan CR karena harus dikerjakan

secara manual, sulit sinkronisasi data

antara proses dan user yang berbeda.

Proses pendataan secara manual cukup memakan waktu dan rawan terjadi

kesalahan sehingga kinerja pegawai pun menjadi kurang efektif. Oleh karena itu

diberikan solusi untuk membuat sistem online dalam bentuk web sehingga data yang

dihasilkan lebih akurat dan cepat dalam hal memprosesnya.

3.4 Identifikasi Permasalahan

Berdasarkan analisis hasil wawancara terhadap Project Manager, Business

Analyst dan System Analyst, dapat disimpulkan permasalahan yang terjadi adalah

sebagai berikut:

a. Dokumentasi CR secara manual menyulitkan project manager untuk mengolah

data CR.

b. Project manager kesulitan dalam tracking waktu pengerjaan sebuah change

request.

c. Belum ada bentuk laporan / report khusus untuk project manager dalam

pengelolaan pengerjaan CR.

d. Tidak ada sinkronisasi antara CR dan Production CR sehingga rawan terjadi

kesalahan dalam pengubahan status CR.

3.5 Alternatif Pemecahan Masalah

Melihat masalah yang dihadapi, maka penulis memiliki alternatif pemecahan

masalah sebagai berikut:

48

a. Merancang aplikasi berbasis web dengan database untuk menyimpan data-data

change request beserta historinya.

b. Merancang berbagai modul yang menampilkan detail dan status pengerjaan

change request.

c. Membuat report-report yang akan mempermudah project manager, business

analyst dan system analyst untuk mengatur dan menganalisis change request

yang ada.

d. Membuat modul PCR dimana pengguna bisa mencetak PCR form yang berisi

detail file yang dihasilkan oleh pengerjaan CR untuk selanjutnya masuk ke tahap

produksi.

3.6 Ruang Lingkup Implementasi Solusi

Berdasarkan alternatif pemecahan masalah yang diusulkan, maka dapat

ditentukan bahwa ruang lingkup pembuatan aplikasi Change Request Management

berbasis web ini adalah:

a. Pembuatan modul all-in-one portal dalam bentuk layar Latest Update dan list CR

dengan status OPEN, ASSIGNED, DONE, PENDING (untuk Project Manager),

New Assigned Project dan Current Project (untuk Business Analyst), Current

Project (untuk System Analyst) yang bisa diakses melalui menu Home masing-

masing pengguna.

b. Pembuatan form input CR untuk mendata CR yang baru.

c. Pembuatan modul yang menampilkan detail CR.

d. Pembuatan form update CR untuk menambah maupun mengubah isi CR.

49

e. Pembuatan tampilan laporan sesuai dengan kebutuhan Project Manager, baik

dalam bentuk laporan CR maupun workflow report yang menampilkan detail

proses persetujuan CR sebelum di-assigned ke BA.

f. Pembuatan modul PCR sesuai kebutuhan System Analyst dengan fitur print PCR

Form dan sinkronisasi perubahan status CR.

g. Pembuatan modul pengaturan user yang hanya bisa diakses oleh admin (Project

Manager) untuk penambahan user secara dinamis sesuai kebutuhan.

bab 3 analisis sistem berjalan 3.1 gambaran umum ...thesis.binus.ac.id/doc/bab3/2012-1-00097-bab...

Documents