BAB I

PENDAHULUAN

1.1 Latar Belakang

Persaingan bisnis dewasa ini tak hanya bertumpu pada kualitas produk,
melainkan lebih pada kualitas layanan, yang lebih mendorong pelanggan untuk
kembali membeli produk atau menggunakan solusi yang kita tawarkan. Namun,
tidak berarti produk yang Anda pasarkan boleh yang tidak bermutu, terutama jika
produk yang ditawarkan memiliki pesaing yang kurang lebih sama. Lain halnya
untuk produk-produk yang secara esensial bersifat unik, bermutu tinggi dan
memiliki diferensiasi yang kuat, sehingga pelanggan akan memiliki value yang
jelas, meskipun ada produk-produk yang sejenis.
Strategi bisnis yang hasilnya diharapkan akan mengoptimalkan tingkat
keuntungan pendapatan dan kepuasan pelanggan. Hal ini dilakukan dengan cara
mengorganisasikan segmen-segmen pelanggan, mengarahkan organisasi agar
berorientasi kepada kepuasan pelanggan dan mengimplementasikan proses bisnis
yang berfokus kepada pelanggan.
Penerapan CRM hanya akan optimal apabila dibantu dengan teknologi. Sebab,
dengan bantuan teknologi maka CRM akan meningkatkan pengetahuan yang
mendalam tentang pelanggan, meningkatkan akses bagi pelanggan, menciptakan
interaksi dengan pelanggan yang lebih efektif dan integrasi melalui seluruh
saluran (channels) serta fungsi-fungsi internal (back office) perusahaan. Tanpa
teknologi yang tepat, solusi CRM tidak akan optimal.
Di luar itu pelanggan dapat berinteraksi dengan perusahaan memandang bisnis
sebagai satu kesatuan, walaupun sering berinteraksi dengan sejumlah karyawan
dalam berbagai peran dan departemen. CRM adalah sebuah kombinasi dari
kebijakan, proses, dan strategi dilaksanakan oleh sebuah organisasi untuk
menyatukan interaksi dengan pelanggan dan menyediakan alat untuk melacak
informasi pelanggan.
Apakah sistem pelayanan pelanggan yang telah ada pada perusahaan mampu
menangani perkembangan kondisi perusahaan dan apakah akibat dari tidak

1
digunakannya sistem pelayanan pelanggan maka keluhan pelanggan terhadap
perusahaan akan lama dalam penangannya, hal ini juga mengakibatkan kemajuan
perusahaan akan terhambat disertai pengurangan customers atau pelanggan
dikarenakan pelayanan yang kurang memuaskan.

1.2 Rumusan Masalah

Bagaimana merancang dan membuat suatu sistem pelayanan pelanggan yang
dapat meningkatkan hubungan dengan pelanggan. Sistem ini dibutuhkan karena
kebutuhan setiap pelanggan akan suatu permintaan selalu berbeda. Maka
perusahaan harus dapat memenuhi setiap kebutuhan pelanggan untuk tetap
menjaga kualitas pelayanan dan kepuasan pelanggan. Pada sistem dapat
digunakan sebagai suatu acuan untuk perusahaan agar terus dapat memperbaiki
mutu manajemennya dari waktu ke waktu dan dapat disesuaikan dengan kondisi
yang sedang terjadi.

1.3 Maksud Dan Tujuan

Maksud dan tujuan tugas akhir ini adalah untuk menganalisa dan
merancang Sistem Customer Relationship Management pada The Pakubuwono
Residence.

1.4 Batasan Masalah

Untuk menghindari pembahasan yang terlalu luas, penyelesaian tugas
akhir ini memiliki batasan-batasan masalah yang dibuat tanpa bermaksud
menghilangkan maksud dan tujuan awal pembuatannya. Batasan-batasan masalah
tersebut adalah ulasan mengenai Customer Relationship Management meliputi
aktivitas pengirimana data klaim oleh pelanggan pelanggan hingga masalah
dipecahkan dan lebih aktivitas pencatatan laporan tentang statistik data klaim
yang terjadi di perusahaan tersebut.
Sehingga keluhan pelanggan dapat diteruskan kepada bagian atau divisi
yang bersangkutan untuk ditindak lanjuti. Dari mulai keluhan yang bersifat
perbaikan sarana, penambahan fasilitas dan mutu pelayanan perusahaan sehingga
dapat ditingkatkan lagi. Untuk proses penyuplaian bahan bakunya (SCM) sendiri
tidak disertakan dalam Tugas Akhir ini karena SCM bahan baku material
ditangani langsung oleh perusahaan dan pihak vendornya dan diluar konteks
Tugas Akhir ini.

2
1.5 Metodologi Penelitian
Untuk memperoleh hasil yang diinginkan, penulis melakukan metode
waterfall yang meliputi :
1. System Engineering
Proses membandingkan sistem lama yang sedang berjalan dan studi
kelayakan dalam sistem yang baru didasarkan pada aspek PIECES
(Performance Information Economic Control Efficiency Services).
2. Analisis
Perolehan kebutuhan pengguna sistem dari user serta pilihan solusi jenis
sistem informasi yang akan dikembangkan pada perusahaan.
3. Desain
Proses ini digunakan untuk mengubah kebutuhan-kebutuhan pada tahap
system engineering dan analisis menjadi representasi ke dalam bentuk
software. Desain harus dapat mengimplementasikan kebutuhan yang telah
disebutkan pada tahap sebelumnya maka proses ini juga harus
didokumentasikan sebagai konfigurasi dari software.
4. Coding Dan Testing
Desain yang dibuat harus diubah dalam bentuk yang dimengerti oleh
komputer, yaitu ke dalam bahasa pemrograman melalui proses coding.
Tahap ini merupakan implementasi dari tahap desain. Proses Coding ini
harus dilakukan Testing untuk menguji kesalahan-kesalahan program
maupun fungsi-fungsi yang ada didalam sistem.
5. Implementasi
Setelah semua fungsi-fungsi yang ada didalam software diujicoba agar
software bebas dari kesalahan, dan hasilnya sesuai dengan kebutuhan yang
sudah didefinisikan sebelumnya. Maka proses selanjutnya adalah sistem
baru akan diinstall dan dijalankan di perusahaan dengan pengoperasian
yang dilakukan oleh user proses ini dinamakan implementasi.
6. Pemeliharaan
Pemeliharaan suatu software sangat diperlukan, termasuk didalamnya adalah
pengembangan, karena software yang dibuat tidak selamanya hanya seperti
itu dan kebutuhuan perusahaan akan terus bertambah juga perkembangan
perusahaan menuntut software harus juga berkembang, seperti ketika ada
pergantian sistem operasi atau perangkat lainnya.

3
1.6 Sistematika Penulisan
Untuk lebih memperjelas gambaran terhadap keseluruhan laporan ini dan
lebih mempermudah pembahasan, maka gambaran secara garis besar mengenai
sistematika penulisan laporan ini adalah sebagai berikut :
BAB I PENDAHULUAN
Bab ini berisi latar belakang, perumusan masalah,maksud dan tujuan,
batasan masalah, metodologi penelitian dan sistematika penulisan tugas
akhir.

BAB II LANDASAN TEORI

Bab ini berisi pembahasan mengenai landasan teori yang menjadi acuan
penulis dalam penulisan tugas akhir ini.

BAB III ANALISA DAN PERANCANGAN

Bab ini membahas analisa dan perancangan sistem. Perancangan tersebut
meliputi desain aplikasi dengan Context Diagram (CD). Perancangan
sistem menghasilkan beberapa bentuk diagram antara lain Flowchart
Diagram, Entity Relationship Diagaram (ERD) dan Data Flow Diagram
(DFD). Analisa dan perancangan mengikuti metode waterfall.

BAB IV IMPLEMENTASI DAN UJI COBA

Bab ini membahas implementasi aplikasi mengenai Customer Relationship
Management yang diterapkan pada perusahaan.

BAB V KESIMPULAN DAN SARAN

Bab ini berisi kesimpulan yang didapat dari seluruh rangkaian tahapan
penelitian dan saran yang diharapkan dapat berguna dalam pengembangan
penelitian selanjutnya.

4
 BAB II
LANDASAN TEORI

2.1 Customer Relationship Management (CRM)

2.1.1 Pengertian
Customer Relationship Management (CRM) adalah suatu jenis manajemen
yang secara khusus membahas teori mengenai penanganan hubungan antara
perusahaan dengan pelanggannya dengan tujuan meningkatkan nilai perusahaan di
mata para pelanggannya.(Sulisworo. 2009)

Pengertian lain mengatakan bahwa CRM adalah sebuah sistem informasi

yang terintegrasi yang digunakan untuk merencanakan, menjadwalkan dan
mengendalikan aktivitas-aktivitas prapenjualan dan pascapenjualan dalam sebuah
organisasi. CRM melingkupi semua aspek yang berhubungan dengan calon
pelanggan dan pelanggan saat ini, termasuk di dalamnya adalah pusat panggilan
(call center), tenaga penjualan (sales force), pemasaran, dukungan teknis
(technical support) dan layanan lapangan (field service). (Sulisworo. 2009)

2.1.2 Sasaran dan Tujuan

Sasaran utama dari CRM adalah untuk meningkatkan pertumbuhan jangka

panjang dan profitabilitas perusahaan melalui pengertian yang lebih baik terhadap
kebiasaan (behavior) pelanggan. CRM bertujuan untuk menyediakan umpan balik
yang lebih efektif dan integrasi. (Sulisworo. 2009)

Otomasi Tenaga Penjualan (Sales force automation/SFA), yang mulai

tersedia pada pertengahan tahun 80-an adalah komponen pertama dari CRM. SFA
membantu para sales representative untuk mengatur account dan track
opportunities mereka, mengatur daftar kontak yang mereka miliki, mengatur
jadwal kerja, memberikan layanan training online yang dapat menjadi solusi
untuk training jarak jauh, serta membangun dan mengawasi alur penjualan dan
juga membantu mengoptimalkan penyampaian informasi dengan news sharing
SFA dan operasi lapangan otomatis ada dalam jalur yang sama dan masuk pasaran

5
pada akhir tahun 90-an mulai bergabung dengan pasar menjadi CRM. CRM
adalah sistem yang sangat komprehensif dengan banyak sekali paket dan pilihan.
(Sulisworo. 2009)

CRM mencakup metode dan teknologi yang digunakan perusahaan untuk

mengelola hubungan mereka dengan pelanggan. Informasi yang disimpan untuk
setiap pelanggan dan calon pelanggan dianalisa dan digunakan untuk tujuan ini.
Proses otomasi dalam CRM digunakan untuk menghasilkan personalisasi
pemasaran otomatis berdasarkan informasi pelanggan yang tersimpan di dalam
sistem. (Sulisworo. 2009)

CRM mencakup berbagai aspek yang berhubungan langsung dengan satu

sama lain : (Sulisworo. 2009)
 Front office operations
Interaksi langsung dengan pelanggan misalnya konfirmasi tentang klaim yang
diajukan oleh pelanggan, panggilan telepon, e-mail, layanan online dll
 Back office operations
Operasi yang pada akhirnya akan mempengaruhi kegiatan di depan kantor
(misalnya : penagihan biaya kepada pelanggan sesuai dengan klaim yang telah
diajukan).
 Business relationships
Pada hal ini, tidak dibahas terlalu luas karena menyangkut masalah hubungan
antara pihak perusahaan dan pihak pemasok bahan baku material (vendor).
Dalam hal ini mencakup scoop SCM (Supply Chain Managemenet), sedangkan
pembahasan pada Tugas Akhir ini adalah CRM (Customer Relationship
Management) yang menyangkut masalah penanganan klaim penghuni
apartemen.
 Analisis
Pada Analisis ini, diterangkan tentang alur sistem klaim, mulai dari pengajuan
klaim hingga penanganannya dan laporan pencatatan tentang statistik data
klaim dalam jangka waktu tertentu. Dimana, data-data dijadikan sebagai suatu
pendukung dari sistem yang dikerjakan dan menjadi acuan untuk pihak
pengelola gedung (Building Management) menjadi evaluasi untuk perbaikan
managemen yang sudah ada.

6
2.2 PHP
PHP adalah singkatan dari Personal home page Hypertext Preprocessor
yang merupakan peranti pemograman web berbentuk skrip yang ditempatkan
dalam server dan diproses di server yang hasilnya dikirimkan ke klien tempat user
menggunakan browser. (Andi. 2004)
Secara khusus PHP didesain untuk membuat suatu web dinamis yang
artinya dapat membentuk suatu tampilan berdasarkan permintaan terkini, semisal
anda ingin membuat suatu tampilan web yang menampilkan berita/informasi
terkini menggunakan isi dari suatu database yang dipilih. (Andi. 2004)
PHP berawal pada tahun 1994 pada saat Rasmus Lerdorf membuat
sejumlah skrip Perl yang dapat mengamati siapa saja yang melihat daftar riwayat
hidupnya. Skrip-skrip tersebut selanjutnya dikemas menjadi tool yang disebut
dengan “Personal Home Page”. (Kurniawan. Rulianto. 2008)

PHP mempunyai beberapa kelebihan sebagai berikut : (Kurniawan. Rulianto.

2008)
- Secara khusus dirancang untuk membentuk web dinamis
- Dapat berkomunikasi dengan database
- Dapat digunakan pada server-server berbasis Linux, Windows, maupun
Macinthos.
- Dapat diintergrasikan dengan berbagai web server seperti apache, Xitami, IIS
(Internet Information Server), PWS (Personal Web Server), dan web server
yang lainnya.
- Memiliki tingkat akses yang lebih cepat
- Mempunyai tingkat keamanan yang tinggi

Untuk mencoba menjalankan PHP anda tidak perlu menggunakan

komputer berkelas server namun cukup dengan komputer biasa anda sudah dapat
menggunakan PHP dengan menggunakan suatu web server. (Kurniawan.
Rulianto. 2008)

7
2.2.1 Manfaat menggunakan PHP

1. Menghilangkan ketidakefisienan waktu, biaya dan tenaga.

2. Lebih sistematis, karena tidak perlu megatur format penulisan.
3. Laporan lebih sistematis, jadi jika terjadi kerusakan atau kehilangan bukti
laporan dapat dilihat dan dicetak ulang sesuai tanggal, bulan dan tahun yang
dinginkan. (Andi. 2004)

2.3 MySQL

MySQL adalah database yang menghubungkan script PHP, menggunakan

perintah quey dan escaps character yang sama dengan PHP. MySQL mempunyai
tampilan client yang mempermudah saya dalam mengakses databse dengan kata sandi
untuk mengijinkan proses yang dapat dilakukan. (Andi. 2004)
Sedangkan phpMyAdmin merupakan halaman yang terdapat pada web
server. Fungsi dari halaman web ini adalah sebagai pengendali databse MySQL
menggunakan web server. (Andi. 2004)
2.4 Flowchart Diagram
Flowchart Diagram adalah salah satu cara penyajian algoritma dengan
menggambarkan langkah-langkah penyelesaian suatu masalah. Ada dua model
atau jenis Flowchart Diagram, yaitu System Flowchart dan Program Flowchart.
(Marliza. 2008)

2.4.1 Tujan Flowchart Diagram

Adapun tujuan dibuatnya Flowchart Diagram, sebagai berikut : (Marliza. 2008)

• Menggambarkan suatu tahapan penyelesaian masalah
• Secara sederhana, terurai, rapi dan jelas
• Menggunakan simbol-simbol standar
Ada dua jenis metode penggambaran program flowchart :
–Conceptual flowchart, menggambarkan alur pemecahan masalah secara
global
–Detail flowchart, menggambarkan alur pemecahan masalah secara rinci

8
2.4.2 Simbol-simbol pada Flowchart Diagram

Simbol-simbol pada diagram flowchart dibagi menjadi 3 bagian, yaitu :

(Marliza. 2008)
A. Simbol Arus
• Simbol arus
– Menyatakan jalannya arus suatu proses

• Simbol hubungan komunikasi

– Menyatakan transmisi data dari satu lokasi ke
lokasi lain
• Simbol konektor
– Menyatakan sambungan dari proses ke proses
lainnya dalam halaman yang sama
• Simbol konektor berhenti
B. Simbol Proses

• Simbol proses
– Menyatakan suatu tindakan (proses) yang
dilakukan oleh komputer
• Simbol manual
– Menyatakan suatu tindakan (proses) yang tidak
dilakukan oleh komputer
• Simbol pertanyaan
– Menujukkan suatu kondisi tertentu yang akan
menghasilkan dua kemungkinan jawaban : ya atau tidak
• Simbol proses pembeda
– Menyatakan penyediaan tempat penyimpanan
suatu pengolahan untuk memberi harga awal
• Simbol terminal
– Menyatakan permulaan atau akhir suatu program

9
 • Simbol operasi kunci
– Menyatakan segal jenis operasi yang diproses dengan
menggunakan suatu mesin yang mempunyai keyboard
• Simbol penyimpanan
– Menunjukkan bahwa data dalam simbol ini akan
disimpan ke suatu media tertentu
• Simbol masukan manual
– Memasukkan data secara manual dengan menggunakan
online keyboard
C. Simbol Masukan / Keluaran

• Simbol masukan / keluaran

– Menyatakan proses masukan atau keluaran tanpa
tergantung jenis peralatannya

• Simbol kartu masukan / keluaran

– Menyatakan masukan berasal dari kartu atau
keluaran ditulis ke kartu
• Simbol pita magnetis
– Menyatakan masukan berasal dari pita magnetis
atau keluaran disimpan ke pita magnetis
• Simbol disk
– Menyatakan masukan berasal dari dari disk atau
keluaran disimpan ke disk

• Simbol dokumen
– Mencetak keluaran dalam bentuk dokumen
(melalui printer)
• Simbol tampilan
– Mencetak keluaran dalam layar monitor

1
 Gambar 2.1 Simbol-simbol pada Flowchart Diagram
2.5 Entity Relationship Diagram (ERD)

ERD adalah suatu penyajian data dengan menggunakan Entity dan

Relationship. Dimana, relationship menghubungkan beberapa table menjadi suatu
relational data base. Setiap tabel mempunyai beberapa entitas-entitas dan
memiliki Primary Key sebagai acuan pada tabel tersebut. Primary bersifat Unique
yaitu yang menjadi pembeda antara dat satu dengan yang lainnya. Biasanya
primary key berupa angka. (Ida Ayu Y. Primashanti. 2007)
Relationship pada ERD dapat berupa 1:1, 1:N dan M:N, dimana
relationahip tersebut merupakan kata kerja. Pada beberapa tabel juga terdapat
Foreign Key, yaitu primary key yang terdapat pada tabel lain. Foreign key
berfungsi sebagai penghubung antara tabel yang satu dengan yang lainnya
sehingga membentuk relationship. (Ida Ayu Y. Primashanti. 2007)

1
2.5.1 Simbol-simbol pada ERD
Simbol-simbol pada ER-Diagram, yaitu : (Ida Ayu Y. Primashanti. 2007)

Gambar 2.2 Simbol-simbol pada Entity Relationship Diagram (ERD)

1
2.6 Data Flow Diagram (DFD)
DFD adalah suatu model logika data atau proses yang dibuat untuk
menggambarkan dari mana asal data dan kemana tujuan data yang keluar dari
sistem, dimana data disimpan, proses apa yang menghasilkan data trsebut dan
interaksi antara data yang tersimpan dan proses yang dikenakan terhadap data
tersebut. (Hartini. 2006)
DFD sering digunakan untuk menggambarkan suatu sistem yang telah ada
atau sistem baru yang akan dikembangkan secara logika tanpa
mempertimbangkan lingkungan fisik dimana data tersebut mengalir atau dimana
data tersebut akan disimpan. (Hartini. 2006)
DFD terdiri dari context diagram dan diagram rinci (DFD Levelled).
Context diagram berfungsi memetakan model lingkungan (menggambarkan
hubungan antara entitas luar, masukan dan keluaran sistem), yang
direpresentasikan dengan lingkaran tunggal yang mewakili keseluruhan sistem.
DFD levelled menggambarkan sistem sebagai jaringan kerja antara fungsi yang
berhubungan satu sama lain dengan aliran dan penyimpanan data, model ini hanya
memodelkan sistem dari sudut pandang fungsi. (Hartini. 2006)

2.6.1 Simbol-simbol pada DFD

Simbol-simbol pada Data Flow Diagram yaitu : (Hartini. 2006)

Gambar 2.3 Simbol-simbol pada Data Flow Diagram (DFD)

1
 BAB III
ANALISA DAN DESAIN SISTEM

3.1 System Engineering

Pada system engineering ini akan membahas alur sistem yang sedang
berjalan pada The Pakubuwono Residence dan alur sitem yang diusulkan dengan
menggunakan PIECES Table.
PIECES Table tersebut menerangkan tentang alur sistem dan akan terlihat
perbedaan antara sistem yang sedang berjalan dan sistem yang diusulkan yang
terdiri dari beberapa aspek yaitu Performance, Information, Economic, Control,
Efficiency dan Services.

3.1.1 Sistem yang sedang berjalan

Pada The Pakubuwono Residence Departemen Engineering untuk layanan
hubungan ke pelanggan sudah tersistem. Tetapi masih banyak kesalahan berupa human
erorr (factor user) maupun kesalahan-kesalahan pada yang terjadi pada sistem. Pada
sistem ini sering terjadi masalah berupa tidak efisiensinya biaya, waktu dan tenaga seperti
penyeleksian pengiriman klaim ke departemen yang dituju, pengindentifikasian klaim
sesuai masalah yang diajukan oleh penghuni, berulang kalinya konfirmasi yang diajukan
oleh pihak pengelola gedung (Building Management).
Service Request Form System ini diperlukan untuk sistem keluhan-keluhan
penghuni (klaim), dimana keluhan tersebut akan langsung dikerjakan sesuai
permintaan penghuni. Dan kita juga dapat melihat hasil laporan mengenai data-
data keluhan yang terjadi hingga pekerjan tersebut sudah dikerjakan dalam jangka
waktu tertentu. Pada saat pengerjaan sistem ini hanya menjadi tinjauan hasil kerja
yang sedang berlangsung. Prosedur Service Request Form System yang sedang
berjalan pada The Pakubuwono Residence dapat dilihat pada Gambar 3.1.

1
 Gambar 3.1 Flowchart Service Request Form System yang sedang berjalan

Proses pada Gambar 3.1 :

1. Penghuni mengajukan klaim ke pihak Pengelola Gedung (Building
Management) pada bagian Tenant Relation Officer (TRO) melalui telepon
atau e-mail.

1
2. Pada saat staff TRO menerima klaim dari penghuni, staff tersebut langsung
menginput data klaim ke sistem.
3. Staff TRO akan membuat Service Request Form (SRF) sesuai dengan data
klaim yang diajukan oleh penghuni.
4. Staff TRO akan meminta persetujuan dari Staff Engineering dan staff TRO
akan memberikan kode layanan pada SRF yang telah dibuat.
5. Apabila diperlukan biaya untuk perbaikan, akan dibuat perincian (estimasi)
biaya sesuai dengan List Harga yang berlaku pada perusahaan. Jika tidak
diperlukan biaya, SRF akan disetujui oleh Chief Engineering. Perbaika yang
tidak memerlukan biaya untuk perbaikan, seperti bencana alam, dll. Dimana
pada hal tersebut masih menjadi tanggung jawab Pengelola Gedung (Building
Management).
6. Lalu, SRF tersebut akan langsung diajukan ke Penghuni (Tenant) untuk meminta
persutujuan penghuni terlebih dahulu. Pada tahap ini, penghuni meenyetujui isi
dari SRF tersebut untuk dikerjakan. Di dalam SRF, tertera tentang rincian biaya
perbaikan dan jenis pekerjaan yang akan dikerjakan oleh Staff Engineering.
7. Setelah SRF disetujui oleh Staff Engineering, Chief Engineering dan
Penghuni, klaim akan langsung dikerjakan oleh Staff Engineering yang telah
menerima Work Request (WO).
8. SRF akan dikirim ke Bagian Account Receivable (AR) untuk dibuat kwitansi
penagihan untuk penghuni.
9. Staff engineering melaporkan pekerjaan ke Bagian Pengelola Gedung
(Building Management) untuk laporan atas pekerjaan yang telah selesai
dilakukannya. Staff Engineering juga melampirkan WO berikut dengan
beberapa catatan perbaikan yang telah dikerjakannya.
10. Bagian AR akan menagih biaya sesuai dengan yang tertera dalam SRF dan
meminta tanda tangan penghuni pada SRF untuk laporan pengerjaan telah
selesai dikerjakan.
11. Staff TRO akan meng-update status pekerjaan menjadi ”Selesai”.

1
3.1.2 Sistem yang diusulkan

Pada sistem yang diusulkan ini, layanan klaim penghuni dapat

langsung diisi oleh penghuni itu sendiri tanpa harus langsung menghubungi
ke Bagian TRO dan beberapa kali konfirmasi tentang klaim yang diajukan
(hanya sekali konfirmasi ke penghuni). Aplikasi ini berfungsi untuk
mengirimkan data klaim yang akan di cek oleh Bagian TRO. Disini saya
mencoba untuk membuat aplikasi yang berbasis web yang menggunakan bahasa
pemrograman PHP dan mysql sebagai database untuk mempermudah dalam
pengerjaannya.
Aplikasi ini hanya dapat diakses di lingkungan apartemen saja
(offline). Aplikasi ini dapat diakses pada komputer yang tersedia di tempat
yang telah ditentukan oleh Bagian Pengelola Gedung. Pada aplikasi ini
pihak pengelola gedung dapat membuat laporan data klaim per bulan dan
Penghuni akan mengisi quistioner yang telah disediakan untuk perbaikan
managemen pada tahap berikutnya. Prosedur Service Request Form System
yang diusulkan pada The Pakubuwono Residence dapat dilihat pada Gambar 3.2.

1
 Penghuni Staff TRO Staff Engineering Bagian AR
& Fit Out Chief Engineering (Account Receivable)

Mulai Staff TRO

menenerima data
klaim dari sistem Staff AR
Penghuni Staff membuat
Mengajukan Klaim Update status data
Rectification/Work
membuat
melalui sistem klaim melalui Reference
Request (WO)
sistem
Rectification /
Tidak Apakah Work request
WO
disetujui?
Ya
WO diterima
oleh penghuni
TRO mengirimkan
WO ke penghuni
untuk persetujuan
Apakah
WO
disetujui
Staff AR
oleh
Setuju Staff membuat
penghuni ? membuat kwitansi
Service
Request
pembayaran
Form (SRF)
Tidak Setuju

Konfirmasi konfirmasi
pekerjaan dan pembayaran
proses pembayaran tagihan

Menerima
Mengisi quistioner yang
Quistioner telah diajukan
melalui sistem oleh Penghuni
melalui sistem

Membuat
laporan data
klaim per bulan
melalui sistem

Tutup SRF

Akhir

Gambar 3.2 Flowchart Service Request Form System yang diusulkan

1
Proses pada Gambar 3.2 :
1. Penghuni mengajukan klaim ke pihak Pengelola Gedung (Building
Management) pada bagian TRO melalui sistem.
2. Staff TRO menerima klaim dari penghuni melalui sistem, staff tersebut
langsung mengkonfirmasi data klaim ke penghuni.
3. Apabila benar, Staff TRO akan melakukan update status pada data klaim
untuk diteruskan ke divisi yang bersangkutan.
4. Staff Engineering / Fit Out membuat Rectification / Work Request (WO)
sesuai dengan data klaim yang dajukan oleh penghuni.
5. Staff TRO akan melakukan konfirmasi dengan Staff AR untuk dibuatkan
perincian biaya sesuai dengan data klaim.
6. Staff AR membuat Reference Rectification / Work request dan diserahkan
kembali untuk dimasukan ke dalam WO.
7. Staff Engineering / Fit Out mengkonfirmasi kepada Chief Engineering untuk
persetujuan WO.
8. Apabila disetujui oleh Chief Engineering, WO akan dikirimkan ke Penghuni
oleh Staff TRO untuk diminta persetujuan Penghuni. Apabila tidak disetujui
maka WO akan diperbaiki oleh Staff Engineering / Fit Out.
9. Apabila WO disetujui oleh Penghuni maka Staff TRO akan membuat Service
Request Form (SRF) dan langsung dikerjakan oleh Teknisi Engineering / Fit
Out. Apabila tidak disetujui maka SRF akan ditutup
10. Setelah pekerjaan selesai dikerjakan oleh Teknisi, maka Staff AR akan
membuat kwitansi pembayaran sesuai dengan yang tercatum pada WO.
11. Staff TRO melakukan konfirmasi tagihan ke Penghuni.
12. Penghuni melakukan konfirmasi pekerjaan dan proses pembayaran kepada
Staff TRO. Setelah itu, Staff TRO melakukan update pada status data klaim
menjadi ”Selesai”.
13. Penghuni mengisi quistioner yang tersedia pada sistem setelah pengerjaan
klaim selesai dikerjakan. Data quistioner yang telah diinputkan oleh Penghuni
akan masuk ke Tabel Quistioner dan data tersebut akan tampil pada account
Staff TRO untuk dijadikan rekapan dan ditindak lanjuti untuk perbaikan.
14. Staff TRO membuat laporan periodik untuk data klaim yang telah terjadi
dalam sebulan.

1
3.1.3 PIECES Table

Pada PIECES Table ini, akan menjelaskan perbandingan antara sistem

lama dengan sisten yang baru. Dimana pola perbandingan tersebut melalui
beberapa aspek yaitu performa, informasi, ekonomi, kontrol, efisien dan
pelayanan. Pada The Pakubuwono Residense, sistem lama sudah tersistem tetapi
kurang memadai. Pada sistem baru ini, saya mencoba membuat sistem dimana
pada sistem tersebut pekerjaan dapat lebih efisien dan efektif. Perbandingan
sistem pada The Pakubuwono Residence dapat dilihat pada Gambar 3.3.

PIECES Sistem Lama Sistem Baru

Performa Pada sistem ini, penghuni harus
menghubungi staff TRO terlebih
dahulu, sehingga jika ada lebih dari
satu penghuni yang mengajukan klaim,
maka jumlah pekerjaan yang dilakukan
oleh staff TRO sehingga membutuhkan
waktu relatif cukup lama.
Informasi Data pada sistem ini belum bisa
diklarifikasikan tujuannya sesuai
dengan jenisnya, sehingga data klaim
yang diajukan langsung masuk ke dua
departemen yang dituju.
Ekonomi Pada sistem ini Penghuni harus
bekomunikasi langsung kepada Staff
TRO baik melalui telepon, e-mail, atau
bertemu langsung pada saat pengajuan
klaim.
Kontrol Pada sistem ini, sudah menggunakan
aplikasi tetapi secara kemanan belum
memadai karena pada aplikasi tersebut
tidak menggunakan password sehingga
kemanan data tidak terjaga. Disini
Penghuni tidak dapat melakukan
pengontrolan proses terhadap klaim
yang telah diajukan.
Pada sistem baru ini, penghuni langsung
dapat menginput klaim ke sistem,
sehingga dalam satu waktu dapat terjadi
lebih dari satu pengajuan klaim dari
penghuni dan beban staff berkurang
karena staff TRO hanya mengecek ulang
data-data klaim yang diajukan oleh
penghuni tanpa harus mengklarifikasi
pekerjaan yang akan dikerjakan oleh
departemen yang bersangkutan.
Pada sistem ini, data dapat
diklarifikasikan sesuai jenis pekerjaannya
sehingga apabila salah satu staff
departemen membuka aplikasi ini hanya
terlihat jenis pekerjaan yang akan
dikerjakannya.
Pada sistem baru ini, penghuni dapat
mengisi langsung melalui aplikasi yang
telah disediakan. Tetapi, perbedaan biaya
tidak terlalu signifikan dibandingkan
dengan sistem lama.
Seperti halnya dengan sistem lama, pada
sistem ini akan menggunakan password
untuk menjaga keamanan data-data.
Password digunakan pada saat user
(penghuni dan staff) melakukan login,
sehingga setiap user memilki account.
Lalu, pada saat staff Fit Out atau
Engineering memasuki account-nya
untuk mengecek klaim yang telah masuk
dan pengontrolan pross pengerjaan oleh
Penghuni terhadap klaim yang diajukan
dapat dicek langsung melalui aplikasi.

2
 Efisien Pada saat penghuni mengajukan klaim,
terlebih dahulu harus menghubungi
staff sehingga memerlukan biaya lebih
untuk mengajukan klaim tetapi pada
saat mengajukan klaim, staff TRO akan
menginputnya.
Pelayanan Pada sistem ini, staff yang mengisi data
klaim yang diajukan oleh penghuni.
Sehingga kecil kemungkinan terjadi
kesalahan (Human Erorr) karena staff
sebelumnya sudah terlatih (trainning).
Pada sistem ini staff TRO hanya
mengecek klaim yang telah diajukan oleh
Penghuni, jika terjadi ketidak validan
data maka Staff TRO akan
mengkonfirmasi kepada Penghuni.
Pada saat penghuni mengajukan klaim, ada
kemungkinan penghuni tidak mengerti
beberapa pilihan klaim karena staff yang
mengerti sistem tersebut sehingga terjadi
kesalahan pada saat pengisian form entry
data klaim oleh penghuni (Human Error).

Gambar 3.3 PIECES Table

3.2 Analisa

Pada analisa ini, menjelaskan user requirement aktor yang menjalankan

sistem. Dimana, setiap aktor mempunyai peran tersendiri dalam sistem Service
Request Form (SRF).

a. User Requirement oleh Penghuni

Pada sistem yang baru ini, hal-hal yang dapat dikerjakan oleh penghuni, yaitu :
1. Mengajukan klaim melalui sistem, dimana penghuni menginput data melalui aplikasi
yang tersedia pada komputer yang sudah disediakan oleh Pengelola Gedung.
2. Menerima SRF yang telah dibuat oleh Bagian TRO.
3. Menyetujui isi dari SRF tersebut.
4. Mengkonfirmasi pekerjaan dan proses pembayaran.

b. User Requirement oleh Staff TRO

Pada sistem yang baru ini, hal-hal yang dapat dikerjakan oleh Staff TRO, yaitu :
1. Menerima data klaim yang diajukan oleh penghuni melalui sistem. Disini,
staff TRO juga dapat menginput data klaim apabila penghuni meminta untuk
mengisikan data klaim.
2. Mengklarifikasi SRF dan estimasi biaya. Dimana pada saat pengklarifikasian
pekerjaan hanya ditujukan ke Departemen Engineering dan Fit Out.
3. Mengirimkan SRF ke penghuni untuk persetujuan penghuni.

2
4. Menutup SRF. Disini, staff TRO mengupdate status pekerjaan menjadi “Selesai”.
c. User Requirement oleh Staff Engineering dan Fit Out

Pada sistem yang baru ini, hal-hal yang dapat dikejakan oleh Staff Engineering
dan Fit Out, yaitu :
1. Setelah menerima WO persetujuan dari penghuni, staff Engineering atau Fit
Out akan mendapatkan surat perintah untuk mengerjakan pekerjaannya yang
dinamakan WO dimana.
2. Membuat Referente Rectification / Work Request No. dan membuat catatan
perbaikan yang tlah dikerjakan.

d. User Requirement oleh Chief Engineering

Pada sistem yang baru ini, hal-hal yang dapat dikerjakan oleh Chief Engineering,
yaitu menyetujui SRF yang telah dibuat oleh staff TRO dan telah ditanda tangani
oleh staff Engineering atau Fit Out.

e. User Requirement oleh Bagian Account Receivable (AR)

Pada sistem yang baru ini, hal-hal yang dapat dikejakan oleh Staff Engineering
dan Fit Out, yaitu :
1. Setelah menerima Reference Rectification / Work Request No. dari staff
Engineering atau Fit Out, AR akan membuat kwitansi penagihan sesuai yang
tertera pada SRF untuk diserahkan ke penghuni.
2. Setelah membuat kwitansi penagihan, AR akan mengkonfirmasi pembayaran
ke penghuni.

3.3 Data Flow Diagram (DFD) Service Request Form

Alur data pada sistem Service Request Form (SRF) The Pakubuwono
Residence akan menerangkan proses-proses sistem SRF pada The Pakubuwono
Residence mulai dari proses pengajuan klaim hingga pekerjaan klaim
terselesaikan. Dimana, laporan pekerjaan dapat dilihat dalam jangka waktu
tertentu. Pada DFD ini saya akan menggunakan simbol-simbol Yourdon / De

2
Marco. Proses tersebut dapat dilihat pada Gambar 3.4, Gambar 3.5, Gambar
3.6, Gambar 3.7, Gambar 3.8, Gambar 3.9, Gambar 3.10 dan Gambar 3.11.

Gambar 3.4 DFD Level 0 Service Request Form

Proses pada Gambar 3.4 :

1. Penghuni menginput username dan password untuk proses login pada aplikasi.
Data diri dibutuhkan pada saat proses pendaftaran untuk membuat account.
Setelah penghuni mempunyai account, penghuni dapat mengirimkan data
klaim ke sistem.
2. Staff TRO akan menerima dan mengecek data klaim dari sistem yang diajukan
oleh penghuni. Staff akan menerima data diri penghuni untuk dibuatkan
account. Staff akan menerima status pembayaran. Staff akan menerima
konfirmasi dari penghuni.
3. Staff akan melakukan konfirmasi untuk status data klaim untuk penghuni.
Staff menginput username dan password untuk melakukan proses login.
Menginput data diri untuk membuat account. Membuat kwitansi pembayaran
untuk penagihan ke penghuni sesuai yang tertera pada SRF. Staff akan
melakukan update pada sistem.
4. Penghuni akan menerima konfirmasi dari staff untuk status data klaim.
Penghuni juga akan mendapatkan account yang berisikan data diri tentang
penghuni.
5. Chief Engineering akan menerima status data klaim dan akan melakukan
update pada data klaim tersebut. Apakah dapat ditndak lanjuti atau tidak.

2
6. Cost Engineering akan menerima data biaya klaim dan akan melakukan
update pada data biaya klaim tersebut. Apakah dapat ditndak lanjuti atau tidak
sebelum disetujui oleh Chie Engineering.

2
 Gambar 3.5 DFD Level 1 Service Request Form
Proses pada Gambar 3.5 :

2
1. Penghuni menginputkan username dan password untuk proses login. Apabila
belum terdaftar, penghuni diharuskan untuk mendaftarkan diri terlebih dahulu
dengan cara menginputkan data diri.
2. Penghuni akan menginputkan data klaim ke sistem. Staff TRO akan langsung
konfirmasi tentang kevalidan data klaim tersebut.
3. Staff TRO akan menerima dan mengecek data klaim dari sistem yang telah
diajukan oleh penghuni. Setelah menerima data klaim tersebut, Staff TRO
akan mengubah status klaim ke penghuni untuk konfirmasi.
4. Staff AR membuat estimasi biaya sesuai dengan data klaim yang telah
diinputkan oleh Penghuni.
5. Staff Engineering / Fit Out membuat WO yang berisikan data beberapa data
WO dan perincian biaya yang telah diinputkan Staff AR ke tabel Harga dan
meminta persetujuan kepada Chief Engineering dan Penghuni.
6. Chief Engineering menerima data WO tersebut melalui sistem. Apabila, WO
disetujui oleh Chief Engineering maka WO akan dicetak dan lalu dikirimkan
ke Penghuni untuk diminta persetujuan.
7. Apabila WO telah disetujui oleh Engineering, Chief Engineering dan
Penghuni, maka Staff TRO membuat SRF untuk surat pengantar pekerjaan
untuk teknisi mengerjakan klaim tersebut.
8. Setelah pekerjaan klaim telah selesai oleh teknisi, maka Staff AR membuat
kwitansi pembayaran untuk proses penagihan pembayaran atas klaim yang
telah diajukan oleh Penghuni.
9. Staff TRO akan menagih kwitansi pembayaran ke penghuni dan konfirmasi
proses pekerjaan klaim. Seelah itu, staff akan melakukan melakukan update
pada status pekerjaan menjadi ”Selesai”.
10. Staff TRO akan melakukan pembuatan laporan mengenai report transaksi
klaim yang sudah terjadi dalam per bulan.
11. Penghuni mengisi questioner yang sudah tersedia pada aplikasi setelah
pengerjaan klaim selesai dilakukan. Lalu, jawaban questioner tersebut
tersimpan pada Tabel Quistioner dan akan dicek oleh Staff TRO untuk
perbaikan managemen yang sudah ada.

2
 Gambar 3.6 DFD Level 2 untuk Pendaftaran Account

Proses pada Gambar 3.6 :

1. Penghuni akan menginput data diri ke sistem untuk proses pendaftaran. Sitem
akan memberikan konfirmasi status account.
2. Staff TRO akan mengecek status pendaftaran melalui sistem. Setelah selesai,
sistem akan konfirmasi ke staff tentang status account yang telah diinput oleh
penghuni. Apakah proses pendaftaran telah berhasil atau tidak dan akan
mengaktifkan account penghuni tersebut.

Gambar 3.7 DFD Level 2 untuk Pengajuan Data Klaim

2
Proses pada Gambar 3.7 :
1. Penghuni menginput menginput data klaim ke sistem pada aplikasi yang telah
disediakan.
2. Data klaim langsung tersimpan ke tabel Klaim. Setelah proses, sistem akan
memberi konfirmasi ke Staff TRO, apakah data yang telah diinput berhasil
atau tidak.
3. Apabila berhasil, Staff TRO akan mengecek data ke sistem dan langsung
mengkonfirmasinya ke Penghuni lewat telepon. Apabila benar, Staff TRO
akan langsung melakukan update status pada data klaim melalui sistem.

Gambar 3.8 DFD Level 2 untuk Estimasi Biaya

Proses pada Gambar 3.8 :

1. Setelah menerima data klaim, Cost Engineering membuat rincian biaya untuk
pengerjaan klaim.
2. Lalu, Cost Engineering melakukan update biaya sesuai dengan daftar list
harga yang berlaku pada The Pakubuwono Residence. Setiap biaya yang
diperlukan jasa instalasi maupun penggantian spare parts akan dimasukkan ke
rincian biaya yang akan disetujui oleh Penghuni. Setelah rincian biaya selesai
dikerjakan, WO tersebut akan dikirimkan ke Chief Engineering untuk
diberikan status pada WO tersebut untuk ditindak lanjuti.

2
 Gambar 3.9 DFD Level 2 untuk Pembuatan WO

Proses pada Gambar 3.9 :

1. Staff TRO melakukan pembuatan WO.
2. Staf TRO memasukkan data harga dari tabel Harga untuk dimasukkan
kedalam daftar harga pada WO.
3. Cost Engineering melakukan update pada data WO. Lalu, Chief Engineering
akan menerima data WO tersebut untuk di cek dan akan memberikan status
pad WO tersebut untuk ditindak lanjuti.

Gambar 3.10 DFD Level 2 untuk konfirmasi pembayaran dan Update Status

2
Proses pada Gambar 3.10 :
1. Staff TRO mengajukan kwitansi pembayaran ke pada penghuni.
2. Penghuni menerima kwitansi tersebut untuk persetujuan pembayaran. Apabila,
tidak bermasalah, kwitansi tersebut akan di tanda tangani oleh penghuni.
3. Setelah pihak Building Management menerima kwitansi pembayaran, Staff
TRO akan melakukan update pada status data klaim penghuni tersebut.
Setelah meng-update status data klaim tersebut penghuni akan mengecek
status data klaim tersebut telah dirubah menjadi ”Selesai”.

Gambar 3.11 DFD Level 2 untuk Laporan Periodik Klaim

Proses pada Gambar 3.11 :

1. Staff TRO melakukan penginputan data laporan untuk data klaim yang telah
terjadi dalam jangka waktu tertentu yang diambil dari tabel Klaim.
2. Data laporan tersebut akan masuk ke dalam tabel Laporan dan hasil akan
ditampilkan sesuai dengan permintaan Staff TRO.

3.4 Data Dictionary (Kamus Data)

Pembentukan kamus data didasarkan atas alur data yang terdapat pada
DFD. Terdapat 6 (enam) proses pada DFD Level 2, yaitu dari proses pendaftaran
account, pengajuan data klaim, estimasi biaya, pembuatan WO, konfirmasi
pembayaran dan update status dan laporan periodik klaim. Terdapat 10 (sepuluh)
proses pada DFD Level 1, yaitu dari proses pendaftaran account, memasuki

3
aplikasi, pengajuan klaim, pembuatan estimasi biaya, pembuatan WO, pembuatan
SRF, pembuatan kwitansi pembayaran, konfirmasi pembayaran dan update status
pekerjaan, pencatatan laporan tentang statistika data klaim dan pengisian
quistioner.

KAMUS ALIRAN DATA

NAMA ALIRAN DATA : Pendaftaran account ; Pengaktifan status account

DESKRIPSI : Form pendaftaran ini diisi oleh Penghuni, Staff

TRO, Staff Engineering atau Fit Out, Staff AR
dan Chief Engineering berisikan tentang data
diri.

DARI : Penghuni

TUJUAN : Proses 2.0. memasuki aplikasi

STRUKTUR DATA : Pengguna = id + nama + no_telp + no_hp + level

+ username + password + divisi + tower + status

Gambar 3.12 Kamus Aliran Data dari DFD Level 1 dari Proses Pendaftaran
Account

3
 KAMUS PENYIMPANAN DATA

NAMA PENYIMPANAN Pengguna

DATA :

DESKRIPSI : Setelah Penghuni mengisi form pendaftaran

maka tahap selanjutnya adalah Staff TRO
mengumpulkan data Penghuni. Hasil dari
form disimpan pada table Pengguna dan dapat
ditampilkan. Tetapi pada saat data telah
diinputkan oleh Penghuni, status account
masih ‘Konfirmasi’ karena keamanan dari
segi user harus diperhatikan sehingga Staff
TRO akan mengupdate status account
Penghuni tersebut dari ‘Konfirmasi’ menjadi
‘Aktif’.

STRUKTUR DATA : Pengguna = id + nama + no_telp + no_hp +

level + username + password + divisi + tower
+ status

VOLUME : Tidak ditentukan berapa jumlah volume

pendaftar karena jumlah pendaftar terbatas
sesuai dengan jumlah tower yang tersedia
karena 1 Penghuni hanya memiliki 1 tower.

AKTIVITAS : Pengaktifan status account

AKSES : Staff TRO

Gambar 3.13 Kamus Penyimpanan Data dari DFD Level 2 dari Proses
Pendaftaran Account

3
 KAMUS ALIRAN DATA

NAMA ALIRAN DATA : Pengajuan data klaim

DESKRIPSI : Penginputan data klaim oleh Penghuni bila

terjadi kerusakan. Lalu Penghuni dapat
melihat isi klaim yang telah diinput dan status
pekerjaan atas klaim tersebut. Data yang telah
diinput oleh Penghuni akan diteruskan kepada
pihak pengelola gedung untuk ditindak lanjuti

DARI : Penghuni

TUJUAN : Proses 4.0 pembuatan estimasi biaya

STRUKTUR DATA : Klaim = id_klaim + kode_klaim + tanggal +

bulan + tahun + dari + towerr + klaim +
keterangan + divisi + status_pekerjaan +
status_data.

Gambar 3.14 Kamus Aliran Data dari DFD Level 1 dari Proses Pengajuan
Data Klaim

KAMUS PENYIMPANAN DATA

3
 NAMA PENYIMPANAN Klaim
DATA :
DESKRIPSI : Tempat penyimpanan data untuk klaim yang
telah diinput oleh Penghuni.
STRUKTUR DATA : Klaim = id_klaim + kode_klaim + tanggal +
bulan + tahun + dari + towerr + klaim +
keterangan + divisi + status_pekerjaan +
status_data.
VOLUME : Bisa lebih dari 1 klaim yang diinput apabila
kerusakan lebih dari 1 jenis kerusakan
AKTIVITAS : Input Klaim ; Lihat Klaim ; Update Status
Pekerjaan
AKSES : Penghuni dan Staff TRO

Gambar 3.15 Kamus Penyimpanan Data dari DFD Level 2 dari Proses
Pengajuan Data Klaim

KAMUS ALIRAN DATA

NAMA ALIRAN DATA : Estimasi Biaya

DESKRIPSI : Berisi tentang perincian biaya untuk pengerjaan klaim

yang telah diinput. Lalu apabila sudah dibuat perician
biayanya maka form perincian biaya tersebut akan
diminta persetujuan terlebih dahulu kepada pihak
Penghuni.

DARI : Staff AR

TUJUAN : Proses 5.0. Pembuatan WO

STRUKTUR DATA : Harga = id + nomor + tanggal + dari + tower + tipe +

klaim + deskripsi + quantity + harga_unit + total +
pengecek + persetujuan + divisi.

Gambar 3.16 Kamus Aliran Data dari DFD Level 1 dari Proses Estimasi
Biaya

KAMUS PENYIMPANAN DATA

3
 NAMA PENYIMPANAN Harga
DATA :

DESKRIPSI : Berisikan tentang perincian biaya yang

dikeluarkan oleh Penghuni untuk pengerjaan
klaim yang telah diinputnya.

STRUKTUR DATA : Harga = id + nomor + tanggal + dari + tower

+ tipe + klaim + deskripsi + quantity +
harga_unit + total + pengecek + persetujuan +
divisi.

VOLUME : Ada 3 tipe yaitu labour, material dan others.

AKTIVITAS : Lihat Klaim ; Input Data Harga

AKSES : Staff AR

Gambar 3.17 Kamus Penyimpanan Data dari DFD Level 2 dari Proses
Estimasi Biaya

KAMUS ALIRAN DATA

NAMA ALIRAN DATA : Pembuatan WO

DESKRIPSI : Pembuatan WO (Work Order atau Work Request)

sesuai dengan klaim yang diinput dan harga yang telah
disetujui oleh Penghuni.

DARI : Staff Engineering atau Staff Fit Out

TUJUAN : Proses 6.0. Pembuatan SRF

STRUKTUR DATA : WO = id_wo + nomor_dokumen + tanggal + auditor +

divisi + dari + tower + permintaan + klaim + harga +
status + tanggal_mulai + waktu_mulai + tanggal_target
+ waktu_target + tanggal selesai + waktu_selesai.

Gambar 3.18 Kamus Aliran Data dari DFD Level 1 dari Proses Pembuatan
WO

KAMUS PENYIMPANAN DATA

3
 NAMA PENYIMPANAN WO
DATA :

DESKRIPSI : Berisikan tentang data-data WO yang telah diinputkan

oleh Staff Engineering atau Staff Fit Out.

STRUKTUR DATA : WO = id_wo + nomor_dokumen + tanggal + auditor +

divisi + dari + tower + permintaan + klaim + harga +
status + tanggal_mulai + waktu_mulai + tanggal_target
+ waktu_target + tanggal selesai + waktu_selesai.

VOLUME : Ada 1 WO untuk 1 permintaan pekerjaan.

AKTIVITAS : Lihat Klaim ; Input WO ; Lihat WO

AKSES : Staff Engineering atau Staff Fit Out

Gambar 3.19 Kamus Penyimpanan Data dari DFD Level 2 dari Proses
Pembuatan WO

KAMUS ALIRAN DATA

NAMA ALIRAN DATA : Konfirmasi Pembayaran dan Update Status

DESKRIPSI : Disini Staff TRO akan menagih pembayaran kepada

Penghuni sesuai dengan harga yang telah disetujui
bersama. Setelah itu Staff TRO akan mengupdate
status pekerjaan menjadi “Selesai”

DARI : Staff TRO

TUJUAN : Proses 9.0. Pencatatan laporan tentang statistika data

klaim

STRUKTUR DATA : Klaim = id_klaim + kode_klaim + tanggal + bulan +

tahun + dari + towerr + klaim + keterangan + divisi +
status_pekerjaan + status_data.

Gambar 3.20 Kamus Aliran Data dari DFD Level 1 dari Proses Konfirmasi
Pembayaran dan Update Status

KAMUS PENYIMPANAN DATA

3
 NAMA PENYIMPANAN Klaim
DATA :

DESKRIPSI : Disini Staff TRO akan menagih pembayaran kepada

Penghuni sesuai harga yang telah disepakati bersama
terlebih dahulu. Setelah itu Staff TRO akan
mengupdate status pekerjaan menjadi ‘Selesai’

STRUKTUR DATA : Klaim = id_klaim + kode_klaim + tanggal + bulan +

tahun + dari + towerr + klaim + keterangan + divisi +
status_pekerjaan + status_data.

VOLUME : Ada 1 kwitansi pembayaran yang diajukan kepada

Penghuni untuk penagihan sesuai dengan jumlah yang
telah disepakati.

AKTIVITAS : Penagihan ; Update Status Pekerjaan Klaim

Gambar 3.21 Kamus Penyimpanan Data dari DFD Level 2 dari Proses
Konfirmasi Pembayaran dan Update Status

KAMUS ALIRAN DATA

NAMA ALIRAN DATA : Pencatatan laporan tentang statistika data klaim

DESKRIPSI : Disini Staff TRO akan membuat laporan tentang

statistika data klaim yang telah terjadi dalam kurun
waktu per bulan. Sehingga dari laporan tersebut dapat
diketahui jenis klaim apa yang sering terjadi sehingga
dapat menjadi acuan untuk perbaikan manajemen
menjadi lebih baik.

DARI : Staff TRO

TUJUAN : Proses 10. Pengisian Quistioner

STRUKTUR DATA : Laporan = id + periodik_bulan + periodik_tahun.

Gambar 3.22 Kamus Aliran Data dari DFD Level 1 dari Proses Laporan
Periodik Klaim

KAMUS PENYIMPANAN DATA

3
 NAMA PENYIMPANAN Laporan
DATA :

DESKRIPSI : Disini Staff TRO akan membuat laporan

tentang statistika data klaim yang telah terjadi
dalam kurun waktu per bulan. Sehingga dari
laporan tersebut dapat diketahui jenis klaim
apa yang sering terjadi sehingga dapat
menjadi acuan untuk perbaikan manajemen
menjadi lebih baik.

STRUKTUR DATA : Laporan = id + periodik_bulan +

periodik_tahun.

VOLUME : Laporan ini dilakukan 1 kali dalam kurun per

bulan.

AKTIVITAS : Input Laporan

AKSES : Staff TRO

Gambar 3.23 Kamus Penyimpanan Data dari DFD Level 2 dari Proses Laporan
Periodik Klaim

KAMUS ALIRAN DATA

NAMA ALIRAN DATA : Login

DESKRIPSI : Semua User yang accountnya sudah diaktifkan maka

dapat melakukan proses login terlebih dahulu sebelum
melakukan proses transaksi.

DARI : Penghuni ; Staff TRO ; Staff Engineering atau Staff Fit

Out ; Staff AR ; Chief Engineering

TUJUAN : Proses 3. Pengajuan data klaim

STRUKTUR DATA : Pengguna = id + nama + no_telp + no_hp + level +

username + password + divisi + tower + status.

Gambar 3.24 Kamus Aliran Data dari DFD Level 1 dari Proses Memasuki Aplikasi

KAMUS PENYIMPANAN DATA

3
 NAMA PENYIMPANAN SRF
DATA :

DESKRIPSI : Tempat data-data SRF yang telah diinputkan oleh Staff

Engineering atau Staff Fit Out.

STRUKTUR DATA : SRF = id_wo + nomor_dokumen + tanggal + auditor +

divisi + dari + tower + permintaan + klaim + harga +
status + tanggal_mulai + waktu_mulai + tanggal_target
+ waktu_target + tanggal selesai + waktu_selesai +
pengecek + persetujuan.

VOLUME : 1 SRF untuk 1 pekerjaan yang dikerjakan

AKTIVITAS : Pencatatan laporan perbaikan yang telah dilakukan.

AKSES : Staff Engineering atau Staff Fit Out

Gambar 3.25 Kamus Penyimpanan Data dari DFD Level 1 dari Proses
Pembuatan SRF

KAMUS PENYIMPANAN DATA

NAMA PENYIMPANAN Harga

DATA :

DESKRIPSI : Membuat kwitansi penagihan atas pekerjaan yang telah

dilakukan.

STRUKTUR DATA : Harga = id + nomor + tanggal + dari + tower + tipe +

klaim + deskripsi + quantity + harga_unit + total +
pengecek + persetujuan + divisi

VOLUME : Minimal 1 orang yang menulis artikel per hari

AKTIVITAS : Lihat Kwitansi.

AKSES : Staff AR (Account Receivable)

Gambar 3.26 Kamus Penyimpanan Data dari DFD Level 1 dari Proses
Pembuatan Kwitansi

3
 KAMUS ALIRAN DATA

NAMA ALIRAN DATA : Quistioner

DESKRIPSI : Pengisian quistioner yang dilakukan oleh Penghuni

dimana quistioner tersebut berisikan 5 pertanyaan dan
sebuah komentar. Quistioner ini diharapkan dapat
membantu pihak pengelola gedung dalam perbaikan
manajemennya agar menjadi lebih baik.

DARI : Penghuni

TUJUAN :

STRUKTUR DATA : Quistioner = id + dari + tower + tanggal +

pertanyaan_1 +. pertanyaan_2 + pertanyaan_3 +
pertanyaan_4 + pertanyaan_5 + komentar

Gambar 3.27 Kamus Aliran Data dari DFD Level 1 dari Proses Pengisian
Quistioner

KAMUS PENYIMPANAN DATA

NAMA PENYIMPANAN Quistioner

DATA :

DESKRIPSI : Pengisian quistioner yang dilakukan oleh Penghuni

dimana quistioner tersebut berisikan 5 pertanyaan dan
sebuah komentar. Quistioner ini diharapkan dapat
membantu pihak pengelola gedung dalam perbaikan
manajemennya agar menjadi lebih baik.

STRUKTUR DATA : Quistioner = id + dari + tower + tanggal +

pertanyaan_1 +. pertanyaan_2 + pertanyaan_3 +
pertanyaan_4 + pertanyaan_5 + komentar

VOLUME : Minimal 1 quistioner setelah dilakukannya pekerjaan

atas klaim.

AKTIVITAS : Input Quistioner ; Lihat Quistioner

AKSES : Penghuni dan Staff TRO

Gambar 3.28 Kamus Penyimpanan Data dari DFD Level 1 dari Proses
Pengisian Quistioner

4
3.5 Entity Relationship Diagram (ERD) Service Request Form
Entity Relationship Diagram (ERD) database pada Aplikasi Service Request
Form (SRF) menggunakan 9 tabel yang berisikan entitas-entitas. Tabel tersebut akan
terdiri dari tabel Pengguna, List Klaim, Klaim, Laporan, WO, SRF, Harga, List
Harga dan Quistioner. Tabel-tabel itu saling terhubung dan membentuk relationship.
Dimana, pada relationship tersebut terdapat kardinalitas. ERD database SRF dapat
dilihat pada Gambar 3.29.

4
41
Gambar 3.29 ERD (Entity Relationship Diagram)
4
3.6 Mapping

Mapping tabel-tabel pada database digunakan untuk menentukan relasi

antar tabel dimana setiap tabel mempunyai Primary Key dan Foreign Key.
Dimana Foreign Key pada setiap tabel akan terhubung dengan Primary Key
pada tabel yang lainnya sehingga membentuk sebuah relasi. Dimana pada setiap
tabel berisikan entitas-entitas. Tabel-tabel pada database terdapat 8 tabel yang
terdiri dari tabel Pengguna, List Klaim, Klaim, Laporan, WO, SRF, Harga, List
Harga dan Quistioner. Mapping dapat dilihat pada Gambar 3.30.

4
 Pe ng gun a K la i m W O SR F
Pk ID In t 5 Pk ID _ K l a i n In t 9 Pk I D _W O I nt 6 Pk ID In t 6
fk N om o r
I nt 6 fk N o m or In t 6
Nam a V a rc ar 30 T an g g al In t 2
Ta n gg a l Date Ta ng ga l D a te
ID IN T 5
N o . T elp . In t 15 A ud it or VC 20
A u di to r V C 20
T o w er V C 50 D i v i si V C 20
D iv is i VC 20
N o. H P In t 15 fk D a ri V C 20
K l a im V C 1 00 fk ID IN T 5
T ow e r V C 6
L e v el V C 30 K e t e ra n g a n T ex t To w e r VC 20
P e r m in ta a n V C 20
U s e rn a m e V C 15 D iv isi V C 20 P er m i nt a a n VC 20 fk K l a im V C 1 00
S ta t u s _ P e ke r j a a n V C 20 fk K la i m VC 10 0 T a n g g a l_ M u l a i D a te
P as s w o r d V C 15
H a r ga I nt 9 W a ktu _ M u la i Ti m e
S ta t u s _ D a t a V C 20
D iv isi V C 30 Ta n gg a l_ M ula i Date
T a n g g a l _ T a r ge t D a te
T ah u n In t 4
W a ktu _T a r ge t Ti m e
T o w er V C 20 Wa k tu _ M u la i T im e
B u lan V C 20 T a n g g a l_ S e le s a i D a te
Ta n gg a l _ T a rg e t Date
S tatu s V C 20 K o d e _ K laim V C 6 W a ktu _S e l e sa i Ti m e
Wa k tu _T a r g e t T im e
L o ka s i V C 20
Ta n gg a l_ S e le sa i Date P e n g e c ek V C 20
Wa k tu _S e le s a i T im e P e r se t uju a n V C 20

S ta tu s VC 20 S ta t us V C 20

Qu is ti on er L i s t_ K la im H ar g a L i s t h a rg a
Pk ID Int 5 Pk ID In t 5 Pk ID Int 6 Pk ID Int 6
ID _ L i s t _ H a r g a V C 6
Ta n g g al D at e Pk N om or Int 6
Fk Fk K o d e K laim VC 10 T ip e V C 10
ID IN T 5 T owe r V C 6
D e s k r ip s i V C 100
To w e r V C 10 T ip e V C 20
Jen is VC 50 H a rg a _ U n i t Int 9
P er tan y a an 1 V C 20 D e s k ri p s i V C 100 D i vi s i V C 20
Fk
P er tan y a an 2 V C 20 D i v i si VC 20 Q ty Int 3
K o d e _ K l aim V C 6
K l aim V C 100
P er tan y a an 3 V C 20 H a rg a _ U n i t Int 9
A u d ito r VC 20
P er tan y a an 4 V C 20 T o tal Int 9
L a p o ra n

P er tan y a an 5 V C 20 L am a h ar i In t 3 fk Pk ID In t 6
K la im Int 9
P e r i o d ik _ B u l a n In t 2
P en g e ce k V C 30
P e r i o d ik _ T a h u n In t 4
P er s et u ju a n V C 30
Fk K laim VC 100

Gambar 3.30 Mapp

43

4
 BAB IV
IMPLEMENTASI DAN UJI COBA

4.1 Implementasi
Kelas-kelas yang digunakan pada Aplikasi Service Request Form ini
mempunyai beberapa file. Total file seluruhnya ada 66 file PHP, yang terdiri dari 43
interface, 30 fungsi, 2 koneksi.

4.2 Uji Coba

4.2.1 Proses Login dan Daftar
Untuk pemanggilan web langkah-langkah yang perlu dilakukan sebagai
berikut :
1. Buka browser yang tersedia pada computer
2. Setelah browser terbuka, ketik pada sitename htpp://localhost/srf seperti
pada Gambar 4.1.

Gambar 4.1 Pemanggilan Aplikasi Service Request Form

Setelah, melakukan pemanggilan pada aplikasi tersebut, browser akan

menampilkan index aplikasi tersebut. Design untuk aplikasi tersebut disimpan pada
localhost. Index pada Aplikasi Service Request Form dapat dilihat pada
Gambar 4.2.

4
 Gambar 4.2 Index

Pada index ini, terdapat form untuk login. Dimana, sebelum User memasuki
aplikasi tersebut ke tahap selanjutnya, User harus mengisikan Username dan Password
masing-masing yang sudah terdaftar terlebih dahulu untuk proses memasuki account.
Apabila User belum terdaftar atau mempunyai account maka User dapat melakukan
pendaftaran dengan cara klik ”DAFTAR” untuk memasuki form pendaftaran. Form
DAFTAR dapat dilihat pada Gambar 4.3.

4
 Gambar 4.3 Form DAFTAR

Pada form DAFTAR ini, User harus mengisi data diri User baik dengan level
Penghuni maupun Staff untuk proses pendaftaran. Setelah menginput data diri, data
diri user tersebut langsung terisi pada tabel Pengguna. Setelah proses penginputan data
dri User akan diberikan konfirmasi untuk proses keberhasilan pendaftaran data diri User
seperti pada Gambar 4.4.

4
 Gambar 4.4 Proses konfirmasi pendaftaran

Pada proses konfirmasi ini data diri yang telah diinput oleh User telah berhasil
dilakukan. Dimana, User telah terdaftar dan telah mendapatkan account. Tetapi, status
account User tersebut masih berstatus Konfirmasi. Hal ini dilakukan untuk menjaga
agar tidak sembarang orang dapat memasuki aplikasi karena sistem ini dijalankan
offline pada komputer yang telah disediakan pada fasilitas-fasilitas umum pada area The
Pakubuwono Residence.
Setelah data dirin User berhasil diinput, untuk mengubah status account User
tersebut dapat dilakukan dengan cara meng-klik Aktif pada kolom Status untuk
mengaktifkan status account User. Pada hal ini, hanya Staff TRO yang mempunyai hak
akses untuk pengaktifan status account tersebut. Proses tersebut dapat dilihat pada
Gambar 4.5.

4
 Gambar 4.5 Form untuk mengaktifkan Status Account User

Sebelum melakukan pengaktifan pada status account User tersebut, Staff TRO
akan melakukan mengkonfirmasi proses pendaftaran tentang kevalidan data diri yang
telah diisi oleh User tersebut melalui telepon. Apabila data yang diisi oleh User valid,
maka Staff TRO akan langsung mengaktifkan account User tersebut. Apabila ternyata
data yang diisikan oleh User tidak valid, maka Staff TRo akan langsung menolak
account User tersebut dan data yang telah diinput oleh User tersebut akan langsung
dihapus dari table Pengguna.

4
4.2.2 Proses Penginputan Klaim
Pada proses penginputan klaim ini, dilakukan oleh Penghuni apartemen. Dimana,
pada saat Penghuni telah melakukan proses login maka akan masuk ke account
Penghuni. Setelah sukses melalui proses login maka akan masuk ke form Home.
Dimana, pada form tersebut berisikan data diri dari Penghuni sesuai dengan yang telah
diinputkan oleh Penghuni pada proses pendaftaran. Tampilan Home tersbut dapat
dilihat pada Gambar 4.6.

Gambar 4.6 Form Home

Pada form Home ini terdapat keterangan tentang data diri Penghuni yang telah
terdaftar. Pada form ini terdapat button Klaim. Button tersebut akan menampilkan form
untuk menginputan data klaim yang dapat dilihat pada Gambar 4.7.

5
 Gambar 4.7 Form Input Klaim

Pada form ini, Penghuni menginput data-data klaim sesuai dengan kerusakan
atau keluhan yang dialami oleh Penghuni. Dimana, Tanggal penginputan klaim akan
terisi langsung secara otomatis disesuaikan dengan tanggal penginputan data
berlangsung. Begitupun, dengan data Dari akan terisi langsung sesuai dengan nama
Penghuni pemilik tower. Untuk Tower juga terisi secara otomatis sesuai dengan tower
Penghuni bertempat tinggal. Lalu, jenis klaim akan disesuaikan dengan kerusakan atau
keluhan yang terjadi. Terakhir, Keterangan akan berisikan tentang keterangan-
ketrangan dari kerusakan atau keluhan yang terjadi. Untuk jenis klaim akan diteruskan
ke divisi yang bersangkutan sesuai dengan jenis pekerjaan yang dikerjakan. Setelah data
klaim diinput maka sistem akan mengkonfirmasikan tentang berhasil atau tidaknya data
diinput seperti dapat dilihat pada Gambar 4.8.

5
 Gambar 4.8 Form konfirmasi penginputan data klaim

Setelah data klaim diinput sistem akan memberikan konfirmasi tentang data-data
klaim yang telah berhasil diinput oleh Penghuni. Dimana, data-data klaim tersebut akan
masuk ke dalam tabel Klaim. Setelah konfirmasi selesai maka Penghuni dapat melihat
status data klaim yang telah diinput dengan meng-klik FORM KLAIM dan akan
menampilkan tentang status data-data klaim seperti pada Gambar 4.9.

5
 Gambar 4.9 Form status data klaim
Pada Gambar 4.9 tersebut menjelaskan tentang status data klaim yang telah
diinputkan oleh Penghuni. Dimana, berisikan Tanggal, yang berisikan tanggal
pengajuan klaim. Klaim, berisikan jenis klaim yang diajukan oleh Penghuni sesuai
dengan kerusakan atau keluhan yang terjadi. Divisi, berisikan divisi manakah yang akan
mengerjakan klaim tersebut. Disini, hanya ada 2 divisi yang mengerjakan yaitu
Engineering dan Fit Out. Status, yang berisikan status pengerjaan klaim. Disini, ada 5
status pekerjaan yaitu Diterima, Konfirmasi, Persetujuan, Dikerjakan dan Selesai.
Lalu, pilihan terakhir adalah DELETE untuk menghapus data klaim dari form status
data klaim.

4.2.3 Proses Penanganan Klaim

Pada proses penanganan klaim ini, dilakukan oleh Staff TRO, Staff Engineering,
Staf Fit Out, Staff AR dan Chief Engineering. Dimana, pada saat Penghuni telah
melakukan proses input data klaim. Setelah data klaim tersebut fiterima oleh Staff
TRO, Staff TRO akan mengupdate status klaim tersebut untuk ditindak lanjuti ke
departemen yang bersangkutan. Tampilan tersebut dapat dilihat pada Gambar 4.10.

5
 Gambar 4.10 Form Update status data klaim

Pada saat Staff TRO mengupdate status data klaim yang telah diinputkan oleh
Penghuni, data klaim tersebut akan langsung diterima oleh divisi yang bersangkutan
untuk ditindak lanjuti sesuai prosedur. Setelah diterima oleh divisi yang bersangkutan
maka Staff Engineering akan membuat perincian biaya yang dibutuhkan untuk
pengerjaan klaim tersebut. Tampilan tersebut dapat dilihat pada Gambar 4.11.

Gambar 4.11 Form Perincian Biaya

5
 Setelah perincian biaya telkah dibuat oleh Staff AR, perincian biaya tersebut
akan dimasukan untuk data Work Request / Work Order yang akan dibuat oleh Staff
Engineering atau Staff Fit Out, form Work Order tersebut dapat dilihat pada Gambar
4.12.

Gambar 4.12 Form Inputan Work Request / Wor Order (WO)

Dimana WO ini berisikan tentang biaya yang dibutuhkan untuk pengerjaan
klaim dan waktu pengerjaannya. Data – data tersebut akan masuk ke Tabel WO. Lalu,
Chief Engineering akan menerima data – data WO tersebut melalui sistem seperti pada
Gambar 4.13.

5
 Gambar 4.13 Form WO Chief Chief Engineering

Data Wo yang telah diinputkan oleh Staff Engineering atau Staff Fit Out
tersebut akan masuk ke form Wo Chief Engineering. Apabila Chief Engineering
menyetujui maka data WO itu akan di update status melalui sistem oleh Chief
Engineering sehingga form WO akan dicetak oleh Staff Engineering atau Staff Fit
Out untuk diminta persetujuannya ke Penghuni. Apabila WO tersebut disetujui oleh
Penghuni, Staff Engineering atau Staff Fit Out akan membuat data SRF (System
Request Form) berdasarkan data-data WO yang telah diinput dan disetujui. Form
inputan SRF tersebut dapat dilihat pada Gambar 4.14.

5
 Gambar 4.14 Form Inputan Service Request Form (SRF)

Pada form inputan SRF ini nanti akan dibuat SRF untuk surat keterangan
pengantar untuk pengerjaan klaim yang telah diinputkan oleh Penghuni. Lalu setelah
pengerjaan klaim tersebut selesai, maka Staff Engineering atau Staff Fit Out akan
mengisi form SRF tersebut untuk laporan dan rekapitulasi arsip data. Lalu setelah itu,
Staff AR membuat kwitansi penagihan melalui sistem untuk diserahkan kepada
Penghuni melalui Staff TRO. Staff TRO akan mengkonfirmasi pembayaran kepada
Penghuni dan status pekerjaan. Setelah selesai Staff TRO akan melakukan update
status pekerjaan menjadi “Selesai”. Lalu, Penghuni harus mengisi form questioner yang
telah disediakan pada aplikasi untuk dijadikan acuan tentang kepuasaan Penghuni
terhadap sistem pelayanan yang diterapkan. Form questioner dapat dilihat pada
Gambar 4.15.

5
 Gambar 4.15 Form Quistioner untuk Penghuni

Form ini didisi setelah pekerjaan klaim telah selesai dikerjakan. Tujuan
quistioner ini adalah untuk melihat sejauh mana kepuasaan konsumen terhadap
pelayanan pengerjaan klaim melalui sistem aplikasi ini. Hal ini diharapkan akn terlihat
dalam aspek apa saja hambatan-hambatan yang selama ini sering dikeluhkan oleh
Penghuni sehingga manajemen yang ada dapat lebih diperbaiki dan ditindak lanjuti
untuk kedepannya.
Pada aplikasi ini terdapat form laporan data klaim yang telah terjadi dalam
waktu sebulan. Form laporan tersebut dapat dilihat pada Gambar 4.16.

5
 Gambar 4.16 Form laporan periodic data klaim

Form laporan ini dibuat dengan cara pilih bulan dan tahun yang ingin dipilih.
Lalu tekan Lihat. Lalu keluar tampilan dengan format PDF seperti Gambar 4.17.

Gambar 4.17 Laporan Periodik Klaim per bulan

Form laporan ini bertujuan untuklaporan periodik tentang data klaim per bulan.
Dimana, dari laporan tersebut dapat terlihat jelas jumlah klaim yang sering terjadi pada
waktu sebulan. Sehingga, pihak pengelola gedung dapat menindak lanjuti klaim tersebut
sehingga perbaikan dapat terus dilakukan.

5
 Setelah dilakukan percobaan pada System Request Form (SRF) pada The
Pakubuwono Residence yang diusulkan, dari 30 data klaim yang telah diinput oleh
Penghuni dan telah dikerjakan, kemungkinan klaim yang sering terjadi adalah Install
New Lamp (TL Lamp 1 x 36 watt). Dari percobaan yang telah dilakukan dapat
membantu pihak Pengelola Gedung (Building Management) untuk mengetahui klaim
yang sering terjadi dan dilakukan perbaikan pada jenis klaim tersebut sehingga kualitas
pelayanan terhadap pelanggan menjadi lebih baik. Hal itu dapat dilihat juga dari
tanggapan (responesive) Penghuni lewat quistioner yang telah tersedia pada aplikasi
dimana hasil dari quistioner dapat dikatagorikan ”Baik”.

Gambar 4.18 Laporan Periodik Klaim per bulan yang sudah diimplementasikan

Gambar 4.19 Laporan hasil quistioner yang sudah diimplementasikan

6
 BAB V
KESIMPULAN DAN SARAN

5.1 Kesimpulan

Kesimpulan yang dapat diperoleh dalam pengerjaan System Request Form

yaitu :
 Sistem ini dirancang untuk penanganan klaim atau keluhan Penghuni pada The
Pakubuwono Residence.
 Penggunaan Aplikasi pada sistem ini lebih mudah karena user (Penghuni) hanya
memasukan data-data klaim saja sehingga memudahkan Penghuni dan ditindak
lanjuti secara prosedur.
 Penggunaan aplikasi tersebut menjamin keamanan karena setiap user harus
mempunyai account terlebih dahulu dan kemanan data terjamin karena adanya
proses encryption terhadap password pengguna.
 Dengan sistem yang diusulkan maka tingkat kepuasan Penghuni apartement The
Pakubuwono Residence dapat diperbaiki dimana tingkat kepuasan Penghuni
dilihat dari isian quistioner yang diinputkan oleh Penghuni lewat aplikasi dan
perbaikan manajemen yang telah ada karena pada aplikasi terdapat laporan
periodik per bulan. Dimana pada format laporan tersebut dapat dilihat jenis
klaim yang sering terjadi sehingga pihak Pengelola Gedung (Building
Management) dapat memperbaiki kualitas pelayanannya.

6
5.2 Saran
Setelah dilakukan analisa dan pengembangan perangkat lunak, maka saran yang
bisa diberikan adalah sebagai berikut :
 Mengingat sistem ini digunakan hanya untuk pihak – pihak tertentu
(Penghuni dan Pihak Pengelola Gedung), maka diharapkan agar User (Penghuni dan
Pengelola Gedung) dapat menjaga kerahasiaan password yang ada dalam
mengoperasikan sistem.
 Diharapkan Pengelola Gedung (Building Management) menjaga
keamanan data klaim dan Penghuni sehingga kestabilan transaksi klaim tetap terjaga
keamanannya dan kerahasiaannya.
 Diharapkan suatu saat System Request Form (SRF) yang diusulkan dapat
lebih diperbaiki dari segi sistem dan program agar Penghuni dan Pengelola Gedung
dapat lebih mudah dalam pemakaiannya (User Friendly).

6
 DAFTAR PUSTAKA

Andi. 2004. “Aplikasi Program PHP dan MySQL untuk Membuat Website Interaktif”.
Yogyakarta: Andi Offset.

Hartini. 2006. “Analisis Dengan Diagram Aliran Data (DFD)”.

http://www.ilkom.unsri.ac.id/dosen/hartini/materi/VIII_DFD.pdf. 23 November
2008.

Ida Ayu Y. Primashanti. 2007. “Entity Relationship Diagram (ERD)”.

http://www.kur2003.if.itb.ac.id/file/SE6162%20ERD.pdf . 25 Oktober 2008.

Kurniawan. Rulianto. 2008. “Membangun Situs dengan PHP untuk orang awam”.
Jakarta: Maxikom.

Marliza. 2008. “Pengantar Flowchart Diagram (Diagram Alur Data)”.

http://72.14.235.132/search?
q=cache:Y3mUKZWHsgcJ:marliza.staff.gunadarm.ac.id. 10 November 2008.

Sulisworo. 2009. “Customer Relationship Management (CRM)”.

http://blog.uad.ac.id/sulisworo/2009/04/24/customer-relationship-management/.
25 Januari 2010.

Wahana. 2006. “Tutorial 5 hari membuat Website Interaktif dengan Macromedia

Dreamweaver 8”. Yogyakarta : Andi Offset.

6
LAMPIRAN

6
6