i
PENGEMBANGAN DECISION SUPPORT SYSTEMS BERBASIS KEY PERFORMANCE INDICATOR DI DIVISI TENANT RELATION MANAGEMENT
NUR HUSNA NASUTION
PROGRAM STUDI MAGISTER ILMU KOMPUTER SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR BOGOR 2012
ii
PERNYATAAN MENGENAI TESIS DAN SUMBER INFORMASI
Dengan ini saya menyatakan bahwa tesis Pengembangan Decision Support Systems Berbasis Key Performance Indicator di Divisi Tenant Relation Management adalah karya saya dengan arahan dari komisi pembimbing dan belum diajukan dalam bentuk apa pun kepada perguruan tinggi manapun. Sumber informasi yang berasal atau dikutip dari karya yang diterbitkan maupun tidak diterbitkan dari penulis lain telah disebutkan dalam teks dan dicantumkan dalam Daftar Pustaka di bagian akhir tesis ini.
Bogor, Oktober 2012 Nur Husna Nasution NRP G651100221
iii
ABSTRACT
NUR HUSNA NASUTION. Decision Support Systems Development based on Key Performance Indicator in Tenant Relation Management division. Under direction of KUDANG BORO SEMINAR, and SONY HARTONO WIJAYA.
Key performance indicator report is the most importance report for tenant relation management to make’s a decision and as company performance information to manager infront of board of management. Current KPI report in tenant relation management division still developed by un-integrated system that combine all department information report with Microsoft excell. Therefore information system for integrating key performance indicators report among Tenancy, Marketing and Customer Service department is very needed. Development process for key performance indicator reporting system use waterfall method analysis and Unified Modeling Language for modeling system. Creating new system for Tenant Relation Management Division based on integration key performance indicator report in all departments (tenancy, marketing and customer service) will make easier for information data share, and faster in report generation
with real time reporting. The result from key
performance indicator report can help manager to decide when the operational meeting review will be held by Marketing, Engineering, House keeping and Security, when the Marketing should focus on leasing platinum area, and finally decide when marketing should start to find new tenant.
Keyword : decision support systems, key performance indicator, unified modeling language, waterfall,
iv
RINGKASAN
NUR HUSNA NASUTION. Pengembangan Decision Support Systems Berbasis Key Performance Indicator di Divisi Tenant Relation Management. Dibimbing oleh KUDANG BORO SEMINAR, dan SONY HARTONO WIJAYA. Peningkatan kualitas pelayanan terhadap Tenant sangatlah menjadi perhatian manajemen untuk meningkatkan nilai Gedung yang dikelola dalam dunia bisnis. Kondisi saat ini mengharuskan Divisi Tenant Relation management untuk melakukan rekapitulasi secara manual ataupun secara sistem yang berbeda untuk membuat suatu laporan key performance indicator. Hal ini membutuhkan waktu yang lama hanya untuk mengeluarkan suatu laporan dan tidak secara real time. Situasi tersebut akan terus berulang setiap akan terbitnya laporan yang secara biaya akan bertambah dan akan mengurangi efektivitas dan efisiensi kerja dari karyawan. Guna mencapai kebutuhan tersebut pengembangan suatu sistem informasi perangkat lunak yang terintegrasi sangatlah dibutuhkan. Dengan Pengembangan Aplikasi Decision Support Systems berbasis KPI ini dapat mengatasi segala permasalahan yang timbul pada divisi Tenant Relation Management saat ini sehingga memberikan gambaran apa saja target yang tidak tercapai. Sistem informasi yang diterapkan harus dapat mengintegrasikan informasi yang berasal dari divisi Tenant Relation Management (TRM) ke divisi-divisi lainnya sehingga proses sharing information di antara divisi dapat berjalan secara otomatis tanpa adanya proses manual. Hal tersebut sangat diharapkan manajemen untuk melakukan kontrol terhadap keluhan atau permintaan yang masuk. Penerapan key performance indicator di Divisi Tenant Relation Management dapat memberikan pihak manajemen kontrol terhadap jalannya operasional sehari-hari untuk landasan dalam pengambilan keputusan yang berpengaruh terhadap 3 departemen di bawahnya, yaitu : Departemen Tenancy, Departemen Marketing & Leasing dan Departemen Customer Service Kebutuhan suatu laporan key performance indicator yang cepat dan tepat merupakan suatu hal yang sangat penting agar mampu menghasilkan sejumlah informasi yang bermanfaat bagi manager dalam proses pengambilan keputusan
v
atas aktivitas yang terjadi pada divisi Tenant Relation management. Pengembangan Decision Support Systems dengan menggunakan parameter KPI dalam laporan sebagai acuan kontrol aktivitas kerja divisi Tenant Relation Management (TRM). Pengembangan Decision Support Systems menggunakan parameter KPI dengan cara analisa dan desain sistem informasi yang terintegrasi menggunakan metode Waterfall dan tools Unified Modeling Language (UML) di divisi Tenant Relation Management yang menghasilkan laporan KPI tersebut sebagai bahan dalam pengambilan keputusan di divisi Tenant Relation Management. Dengan adanya Sistem baru divisi Tenant Relation Management yang berdasarkan Key Performance Indicator yang terintegrasi antar departemen mempermudah sharing data, informasi dan pembuatan laporan lebih cepat dan real time. Hasil dari laporan report Key Performance Indicator dapat membantu manajer dalam pengambilan keputusan dalam kapan harus melakukan review operasional Marketing, Engineering, House Keeping dan Security, kapan fokus terhadap penjualan area Platinum, kapan Marketing harus mencari tenant baru dan sebagainya.
Kata Kunci : decision support systems, key performance indicator, unified modeling language, waterfall,
vi
© Hak Cipta milik IPB, tahun 2012 Hak Cipta dilindungi Undang-Undang
1. Dilarang mengutip sebagian atau seluruh isi karya tulis ini tanpa mencantumkan atau menyebutkan sumber a. Pengutipan hanya untuk kepentingan pendidikan, penelitian, penulisan karya ilmiah, penyusunan laporan, penulisan kritik atau tinjauan suatu masalah b. Pengutipan tidak merugikan kepentingan wajar IPB 2. Dilarang mengumumkan dan memperbanyak sebagian atau seluruh karya tulis dalam bentuk apapun tanpa izin IPB
vii
PENGEMBANGAN DECISION SUPPORT SYSTEMS BERBASIS KEY PERFORMANCE INDICATOR DI DIVISI TENAT RELATION MANAGEMENT
NUR HUSNA NASUTION G651100221
Tesis Sebagai salah satu syarat untuk memperoleh Gelar Magister Komputer pada Program Studi Ilmu Komputer
PROGRAM STUDI MAGISTER ILMU KOMPUTER SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR BOGOR 2012
viii
Penguji Luar Komisi : Musthofa, S. Kom, M. Kom
ix
Judul Tesis
: Pengembangan Decision Support Systems Berbasis Key Performance
Indicator
di
Divisi
Tenant
Relation
Management Nama
: Nur Husna Nasution
NRP
: G651100221
Program Studi
: Ilmu Komputer
Disetujui, Komisi Pembimbing
Prof. Dr. Ir. Kudang Boro Seminar, M.Sc
Sony Hartono Wijaya, S.Kom, M.Kom
Ketua
Anggota
Diketahui,
Ketua Program Studi
Dekan Sekolah Pascasarjana
Ilmu Komputer
Dr. Yani Nurhadryani, S.Si, M.T
Dr. Ir. Dahrul Syah, M.Sc. Agr.
Tanggal Ujian : 14 September 2012
Tanggal Lulus :
x
PRAKATA
Puji syukur kita panjatkan kehadirat Allah SWT, atas segala rahmat dan hidayah-Nya sehingga kita selalu dalam keadaan sehat wal’afiat untuk selalu beraktivitas. Alhamdulillah penulis ucapkan, karena penulisan penelitian ini dapat diselesaikan dengan baik. Tema yang dipilih dalam penelitian tesis ini adalah Pengembangan Decision Support Systems Berbasis Key Performance Indicator di Divisi Tenant Relation Management. Penulis mengucapkan terima kasih yang sebesar-besarnya atas bantuan, dukungan dan motivasi baik secara langsung maupun tidak langsung dalam pelaksanaan penulisan penelitian, kepada pihak: 1.
Aa Agus Sofyandi S. Kom,
atas doa, kesabaran, support dan waktu
diskusinya yang telah mendukung dan memotivasi dalam segala hal, memahami dan terus mengingatkan untuk menyelesaikan kuliah di Institut Pertanian Bogor . 2.
Ayahanda Arisman Nasution dan Ibunda Mardiani atas doa dan dukungan agar cepat terselesainya kuliah ini.
3.
Bapak Prof. Dr. Ir. Kudang Boro Seminar, M.Sc selaku ketua komisi pembimbing atas bimbingan, arahan, mengingatkan, motivasi dan doa sejak awal penulisan sehingga memberikan aura positif dan semangat yang tinggi dalam menyelesaikan penulisan tesis.
4.
Bapak Sony Hartono Wijaya S.Kom, M.Kom, selaku anggota komisi pembimbing atas bimbingan, arahan, tantangan dan motivasi dalam menyelesaikan hal-hal desain dan teknis dalam aplikasi.
5.
Ibu Sherly, SE selaku Divisi Tenant Relation Management manager atas informasi yang dibutuhkan dalam bidang Marketing, Tenant Relation dan Customer Service, arahan dan bimbingannya dalam menyelesaikan penulisan ini.
6.
Bapak Muhaemin Toha, SE selaku Project Manager atas ijinnya untuk melakukan penelitian dalam ruang lingkup Divisi Tenant Relation Management.
xi
7.
Anak-anak tercintaku kakak ‘Shabira Zhillan Zhalila’, kakak ‘Karina Zahra Syakira’ dan dede ‘Ghassani Yasra Nasyitha’ atas kesabaran, pengertiannya dan kedewasaan kalian dalam menjalani hidup 2 tahun ini.
8.
Bunda Dr. Ir. Sri Nurdiati, M. Sc atas doa, motivasi dan arahannya sehingga penulis memilih kampus IPB.
9.
Bapak Dr. Ir. Agus Buono, M. Si, M. Kom atas dukungannya kepada kami mahasiswa pascasarjana Ilmu Komputer IPB angkatan XII agar cepat menyelesaikan pendidikan kuliah.
10. Ibu Dr. Yani Nurhadryani, S.Si, M.T atas doa dan motivasi kepada penulis untuk cepat menyelesaikan tesis ini. 11. Para dosen Program Studi Ilmu Komputer Sekolah Pascasarjana Institut Pertanian Bogor yang telah memberikan wawasan pengetahuan bagi penulis. 12. Rekan-rekan seperjuangan S2 Ilkom XII IPB : Safar, Imam, Gibtha, Sari, Yudith, Pak Andi, Mila, Pak Kodar, Asep, Pak Ilyas, Prita, Teh Ana, mbak Dian, Ami, Teh Kania, Yustin, mbak Verra, Mr. G, Pak Komar, Fikri dan Irwan atas dukungan, saling memotivasi, mengingatkan, bantuan dan kebersamaan selama kuliah di Ilkom IPB dan semasa penulisan penelitian. 13. Pak Toto dan Pak Yadi, atas bantuannya dalam memberikan informasi yang berhubungan dengan kuliah dan membantu dalam urusan administrasi pendidikan. 14. Rekan-rekan S2 Ilkom mbak Sinta, Pak Muklis dan Kak Supri atas motivasi dan dukungan untuk menyelesaikan S2 Ilkom IPB.
Serpong, Oktober 2012
Nur Husna Nasution,
xii
RIWAYAT HIDUP
Penulis dilahirkan di Bandar Jaya, Lampung Tengah pada tanggal 1 Februari 1978 dari pasangan Bapak Arisman Nasution dan Ibu Mardiani Nasution sebagai anak kedua dari lima saudara. Penulis meluluskan sekolah dasar pada SD Negeri 3 Bandar Jaya tahun 1991, meluluskan sekolah menengah pertama pada SMP Negeri 1 Poncowati, Terbanggi Besar tahun 1994 dan meluluskan sekolah menengah umum pada SMU Negeri 2 Tanjung Karang, Bandar Lampung tahun 1997. Pada tahun 1997 - 2001, penulis melanjutkan pendidikan S1 di Jurusan Teknik Informatika Institut Sains dan Teknologi Al-kamal Jakarta. 1999 – 2000 Menjadi Asisten Lab. Komputer dan memandu Praktikum Pascal, Fortran dan Assembler. Pada tahun 2010 – 2012 penulis melanjutkan S2 di Ilmu Komputer (ILKOM), Institut Pertanian Bogor. Penulis mengajar di Institut Sains dan Teknologi Al-Kamal Jakarta dari tahun 2006 – 2011. Dalam mata kuliah Bahasa dan Algoritma Pemrograman, Bahasa Rakitan dan Struktur Data, untuk praktikumnya Bahasa Pemrograman Pascal dan Assembler. Sejak tahun 2011, aktivitas penulis konsentrasi kuliah.
xiii
DAFTAR ISI
Halaman
DAFTAR TABEL .....................................................................................
xv
DAFTAR GAMBAR ..................................................................................
xvi
DAFTAR LAMPIRAN ...............................................................................
xviii
PENDAHULUAN .......................................................................................
1
Identifikasi Masalah ........................................................................... 4 Rumusan Masalah ............................................................................. 4 Tujuan Penelitian ...............................................................................
5
Ruang Lingkup Penelitian .................................................................
5
TINJAUAN PUSTAKA ............................................................................
7
Key Performance Indicator (KPI) .....................................................
7
Unified Modeling Language (UML) .................................................
10
Sistem Pendukung Pengambilan Keputusan-Decision Support Systems (DSS) .................................................................................
15
Penelitian Sebelumnya yang Relevan ................................................
19
Perbedaan Penelitian dengan Penelitian Sebelumnya .......................
22
METODE PENELITIAN ...........................................................................
25
Kerangka Pemikiran .........................................................................
25
Kerangka Penelitian ..........................................................................
25
PEMBAHASAN PENGEMBANGAN DECISION SUPPORT SYSTEMS BERBASIS KEY PERFORMANCE INDICATOR DI DIVISI TENANT RELATION MANAGEMENT .....................................................................
29
Study Kebutuhan .............................................................................
29
Kondisi Divisi Tenant Relation Management Saat Ini .................
29
Sistem Divisi Tenant Relation Management di Bidang Properti...
30
Key Performance Indicator Tenant Relation Management Systems .........................................................................................
34
Analisis Proses Divisi Tenant Relation Management .....................
38
Keputusan Manager Divisi Tenant Relation Management ............ 38
xiv
90 Identifikasi Pelaku Bisnis ...........................................................
39
Identifikasi Use Case persyaratan Bisnis .....................................
41
Desain Proses Divisi Tenant Relation Management ......................
45
Model Use Case ............................................................................ 45 Model Activity Diagram ...............................................................
51
Model Class Diagram ..................................................................
56
Model Sequence Diagram ............................................................
62
Implementasi Sistem Tenant Relation Management ......................
65
Menu Program .............................................................................
65
Output / Report Program ..............................................................
72
Pengujian Sistem Tenant Relation Management ............................
85
Evaluasi Report Key Performance Indicator ...................................
86
Implikasi Manajerial di Divisi Tenant Relation Management ......... 91 SIMPULAN DAN SARAN.......................................................................... 93 DAFTAR PUSTAKA .................................................................................
95
LAMPIRAN ...............................................................................................
97
xv
DAFTAR TABEL
Halaman
1,,Perbedaan
Penelitian
yang
Dikembangkan
dengan
Penelitian
Sebelumnya ..............................................................................................
22
2 Daftar Pelaku-pelaku Bisnis Divisi Tenant Relation Management ..........
39
3 Daftar Use Case dalam Divisi Tenant Relation Management ..................
43
xvi
DAFTAR GAMBAR
Halaman
1 Tiga Jenis Ukuran Kinerja .......................................................................
7
2 Menggambarkan Penetapan Tujuan SMART .......................................... 9 3 Keenam Jenis DSS Didasarkan Tingkat Dukungan Pemecahan Masalah 17 4 Kerangka Penelitian ................................................................................
26
5 Diagram Konteks Divisi Tenant Relation Management .......................... 42 6 Diagram Use Case Pengembangan DSS Divisi Tenant Relation Management ............................................................................................
46
7 Diagram Use Case Pengembangan DSS SubSystems Tenant Relation Management ............................................................................................
50
8 Complaint Handling Class Diagram ......................................................
56
9 Request Handling Class Diagram ...........................................................
57
10 Leasing Class Diagram ..........................................................................
58
11 Event Class Diagram ..............................................................................
59
12 Overtime Class Diagram ........................................................................
61
13 Tenant Relation Management Class Diagram ........................................
62
14 Struktur Menu Aplikasi TRM .................................................................. 65 15 Struktur Menu Aplikasi Report Key Performance Indicator ..................
66
16 Tampilan Login Program pada Divisi TRM ............................................ 67 17 Tampilan Input Proses Prospecting Tenant di Departemen Marketing ..
67
18 Tampilan Input Proses Complaint di Departemen Customer Service .....
68
19 Tampilan Input Proses Overtime di Departemen Customer Service .......
69
20 Tampilan Input Proses Data Tenant di Departemen Tenancy.................
70
21 Tampilan Input Proses Contract Facility di Departemen Tenancy .........
71
22 Tampilan Input Proses Target KPI .........................................................
71
23 Tampilan Report Proses Prospecting Tenant .........................................
72
24 Tampilan Report Proses Renewal ...........................................................
73
25 Tampilan Report Proses Complaint .......................................................
74
26 Tampilan Report Proses Overtime ........................................................... 74
xvii
27 Tampilan Report Proses Tenant List .......................................................
75
28 Tampilan Report Proses Facility Agreement ...........................................
76
29 Tampilan Report KPI Proses Complaint Status ....................................... 77 30 Tampilan Report KPI Proses Complaint Response Time ........................
78
31 Tampilan Report KPI Proses Inquiry .....................................................
79
32 Tampilan Report KPI Proses Inquiry Response Time .............................
80
33 Tampilan Report KPI Proses Rental Rate ..............................................
81
34 Tampilan Report KPI Proses Occupancy Rate .......................................
82
35 Tampilan Report KPI Proses Renewal ...................................................
83
36 Tampilan Report KPI Proses Expense .....................................................
84
37 Tampilan Report KPI Proses Income .....................................................
84
38 Report KPI Dashboard Departemen Customer Service ..........................
86
39 Report KPI Dashboard Departemen Marketing ...................................... 88 40 Report KPI Dashboard Expense & Income ............................................
90
xviii
DAFTAR LAMPIRAN
Halaman 1 Call Center Activity Diagram untuk Use Case Complaint Handling dan Complaint Update ................................................................................
98
2 Call Center Activity Diagram untuk Use Case Request Handling dan Request Update .......................................................................................
99
3 Marketing Leasing Activity Diagram untuk Use Case Leasing Prospecting dan Prospecting Progress ................................................
100
4 Marketing Leasing Activity Diagram untuk Use Case LOO Leasing dan Renewal ..........................................................................................
101
5 Marketing Event Activity Diagram untuk Use Case Event Prospecting, Prospecting Progress Event dan LOO Event .....................................
102
6 Tenancy Activity Diagram untuk Use Case Facility Agreement, Tenant Update dan Tenant List Master ............................................................
103
7 Overtime Activity Diagram untuk Use Case Overtime Request dan Overtime Approval ...............................................................................
104
8 Complaint Handling Sequence Diagram .................................................
105
9 Complaint Update Sequence Diagram ....................................................
105
10 Request Handling Sequence Diagram ....................................................
106
11 Request Update Sequence Diagram .......................................................
106
12 Leasing Prospecting Sequence Diagram ...............................................
107
13 Prospecting Progress Sequence Diagram .............................................
107
14 Leasing LOO Sequence Diagram ..........................................................
108
15 Renewal Sequence Diagram ..................................................................
108
16 Event Prospecting Sequence Diagram .................................................... 109 17 Event Progress Sequence Diagram ........................................................
109
18 Event LOO Sequence Diagram ..............................................................
110
19 Facility Sequence Diagram ....................................................................
110
20Tenant Update & Tenant List Sequence Diagram ...................................
111
21 Overtime Request Sequence Diagram ....................................................
111
22 Overtime Update & Approval Sequence Diagram ................................
112
1
BAB I PENDAHULUAN
Berbagai perubahan yang terjadi dalam dunia bisnis, menuntut organisasi untuk membuka diri terhadap tuntutan perubahan dan berupaya menyusun strategi dan kebijakan yang mampu menjawab ketidakpastian lingkungan bisnis. Persaingan sangat ketat dalam bisnis memunculkan situasi yang disebut sebagai hypercompetition (D’Aveni 1994, diacu dalam Djaelani 2009), yang disebabkan oleh berbagai organisasi dalam industri yang sama berlomba–lomba menawarkan pilihan yang disesuaikan dengan kebutuhan konsumen. Esensi dari persaingan bisnis saat ini terletak pada bagaimana sebuah perusahaan dapat mengimplementasikan proses penciptaan produk dan atau jasanya secara lebih murah, lebih baik dan lebih cepat (cheaper, better and faster) dibandingkan dengan pesaing bisnisnya (Indrajit dan Djokopranoto 2002, diacu dalam Djaelani 2009). Dikatakan bahwa saat ini yang menjadi sumber competitive advantage adalah “the ability of the organization to differentiate itself, in the eyes of customers, from its competition and secondly by operating at a lower cost”. Penelitian sebelumnya
menurut
Cai (2009) menjelaskan tentang
keterkaitan atau hubungan antar Key Performance Indicator untuk masing-masing bagian di dalam bidang Supply Chain yang di dukung dengan sistematika untuk pencapaian masing-masing KPI. Penentuan penggunaan metode SCOR (Supply Chain Operation Reference) sebagai alat yang sistematik untuk pengembangan yang memiliki 5 kategori pengukuran yaitu, sumber daya (Resources), keluaran (Output), fleksibilitas (Flexibility), inovasi (Innovativness) dan informasi (Information). Pencapaian suatu KPI sangatlah membutuhkan biaya yang lebih besar atau usaha yang lebih untuk KPI yang lainnya, hal ini berpengaruh terhadap beberapa hal yaitu, informasi yang kurang lengkap, sumber daya yang terbatas, dan keterbatasan komunikasi. Hasil dari penelitian tersebut berupa kerangka kerja (Framework) sebagai dasar penetapan dan pencapaian KPI dan tidak diteruskan ke dalam suatu sistem yang terintegrasi seperti Decision Support Systems (DSS) (Cai, Liu X., Xiao, Liu J., 2009). Valverde (2011) mengangkat suatu penelitian yang mendesain dan membuat Risk Management Systems yang berbasis DSS dengan menggunakan
2
model keputusan yang sudah ada untuk membantu manager dalam pengambilan keputusan investasi di dalam bidang Real Estate seperti kapan harus menjual suatu aset, memilih pembelian suatu aset atau investasi dalam bentuk apapun, penentuan nilai dari suatu aset atau investasi dan lain sebagainya. Hasil dari penelitian tersebut adalah suatu sistem DSS dengan menggunakan Visual Basic Development Tools dan Microsoft Access sebagai Database Engines tetapi tidak didukung oleh sistematik pencapaian dalam bentuk KPI dalam proses pengambilan keputusan. Hal yang sama terjadi pada PT. Buana Sakti yang merupakan perusahaan yang bergerak dalam bidang Pengelolaan Gedung (Perkantoran). Peningkatan kualitas pelayanan terhadap Tenant (Penyewa Perkantoran) sangatlah menjadi perhatian manajemen untuk meningkatkan nilai Gedung yang dikelola dalam dunia bisnis. Untuk mencapai hal tersebut, PT. Buana Sakti sangat menitikberatkan pada kepuasan Tenant yang hampir 93% menghuni gedung yang dikelola oleh PT. Buana Sakti. Hal tersebut dapat diraih dengan meningkatkaan kualitas pelayanan terhadap Tenant di berbagai aspek baik itu dari sisi sumber daya manusia yang selalu berinteraksi dengan Tenant ataupun dari sisi prosedur penanganan keluhan atau permintaan yang diterapkan dalam suatu sistem informasi terpadu, sehingga mempercepat proses penanganan keluhan atau pun permintaan Tenant / non Tenant. Sistem informasi yang diterapkan harus dapat mengintegrasikan informasi yang berasal dari divisi Tenant Relation Management (TRM) ke divisi-divisi lainnya sehingga proses sharing information di antara divisi dapat berjalan secara otomatis tanpa adanya proses manual. Hal tersebut sangat diharapkan manajemen untuk melakukan kontrol terhadap keluhan atau permintaan yang masuk. Dengan adanya sistem informasi, dapat diketahui keluhan-keluhan apa saja yang paling banyak dilaporkan oleh Tenant atau non Tenant, sehingga dapat dilakukan perbaikan/pencegahan agar keluhan tersebut tidak terulang kembali. Untuk melakukan kontrol terhadap keluhan, parameter Key Performance Indicator terhadap jumlah keluhan secara total, nilai persentase hunian (occupancy), waktu respon pihak terkait terhadap keluhan atau permintaan yang masuk dapat diterapkan. Secara keseluruhan penerapan KPI di Divisi Tenant
3
Relation Management dapat memberikan pihak manajemen kontrol terhadap jalannya operasional sehari-hari. Laporan KPI merupakan laporan yang sangat penting bagi divisi Tenant Relation Manajemen untuk landasan dalam pengambilan keputusan yang berpengaruh terhadap 3 departemen di bawahnya, yaitu; a. Departemen Tenancy b. Departemen Marketing & Leasing c. Departemen Customer Service Secara garis besar, semua informasi yang akan digunakan dalam melakukan proses formulasi KPI sudah terdapat dalam sistem yang selama ini digunakan, karena ketidaktersediaan waktu dan personil yang mengakibatkan formulasi KPI tersebut belum dilakukan. Laporan KPI merupakan salah satu elemen dari laporan divisi TRM. Laporan KPI merupakan pengembangan Decision Support Systems (DSS) yang berdasarkan dari parameter-parameter KPI yang ada dan sudah diformulasikan oleh manajer divisi TRM. Laporan KPI harus tersedia setiap bulannya yang akan digunakan sebagai informasi kinerja divisi tersebut dihadapan manajemen. Laporan KPI dari divisi TRM berisi berbagai macam informasi mengenai aktivitas-aktivitas yang dilakukan oleh personil / karyawan di Divisi TRM, seperti service level penanganan keluhan, persentase nilai hunian dan lain-lain. Laporan KPI ini memberikan gambaran dan bantuan kepada manager dalam pengambilan keputusan di divisi Tenant Relation Manajemen dalam hal, kapan melakukan review operasional Engineering, House Keeping, Security dan Marketing, kapan menentukan kenaikan dan penurunan service charge dan rental charge, kapan marketing mencari tenant baru dan lain-lain. Laporan KPI yang ada sekarang di PT Buana Sakti pada divisi Tenant Relation Management masih dilakukan secara sistem yang tidak terintegrasi, dengan
menggabungkan
informasi
masing-masing
departemen
dengan
menggunakan laporan Microsoft Excell, maka diperlukan pengembangan sistem informasi laporan KPI yang terintegrasi ke semua departemen yang terlibat. Dengan adanya pengembangan DSS berbasiskan parameter KPI diharapkan akan lebih mudah dan cepat dalam pengambilan keputusan.
4
Dalam perkembangan dunia teknologi informasi, kebutuhan akan suatu sistem informasi yang dapat memberikan suatu bentuk proses atau laporan yang digunakan untuk proses pengambilan keputusan secara cepat dan tepat sangatlah dibutuhkan. Proses pengembangan suatu sistem haruslah melalui kaidah-kaidah pengembangan sistem yang benar dengan menggunakan metode yang tepat seperti Waterfall dengan tools Metode Unified Modeling Language ( UML ).
1.1 Identifikasi Masalah Dengan mengamati berbagai proses yang ada di Divisi Tenant Relation Management (TRM), ditemukan beberapa proses atau prosedur dan keinginan dari manajemen terhadap Divisi Tenant Relation Management. Beberapa masalah dari manajemen dapat dijabarkan sebagai berikut: a. Banyaknya jumlah complaint atau keluhan tenant b. Keterlambatan dalam pembuatan rekapitulasi keluhan datang dari tenant c. Lambatnya penyampaian informasi keluhan ke departemen terkait d. Keterlambatan data mengenai persentase Occupancy e. Keterlambatan dalam membuat laporan available space untuk setiap bulannya f. Kontrol pengeluaran divisi TRM yang over budget g. Kualitas pelayanan complaint terhadap SDM yang masih perlu ditingkatkan Sejumlah informasi awal ini menjadi masukan berarti, sehingga direncanakan untuk membuat perancangan dan pengembangan sistem untuk mengatasi masalahmasalah tersebut.
1.2 Rumusan Masalah Berdasarkan beberapa temuan permasalahan diatas, maka Perencanaan dan Pengembangan Aplikasi Decision Support Systems berbasiskan parameter KPI perlu dilakukan beberapa hal berikut :
5
a. Identifikasi proses bisnis, komponen utama dan informasi pendukung lainnya dalam proses penyusunan dan pembuatan Decision Support Systems. b. Menggunakan
parameter
KPI
untuk
masing-masing
departemen
berdasarkan kebutuhan laporan KPI yang dibutuhkan. c. Menggunakan metode pengembangan perangkat lunak Waterfall dan tools UML yang digunakan dalam pengembangan Decision Support Systems. d. Pengembangan sistem informasi Decision Support Systems dengan konsep sistem yang terintegrasi.
1.3 Tujuan Penelitian Tujuan dari penelitian ini adalah mengembangan Decision Support Systems dengan menggunakan parameter KPI sebagai acuan kontrol aktivitas kerja dan pengambilan keputusan divisi Tenant Relation Management (TRM).
1.4 Ruang Lingkup Penelitian Ruang lingkup dari penelitian
ini
adalah
Mengembangan DSS
menggunakan parameter KPI yang sudah ada dengan menggunakan data informasi kontrak, Tenant, Complaint dan Inquiry untuk dianalisis dan desain sistem informasi yang terintegrasi sehingga menghasilkan laporan KPI yang membantu manager dalam pengambilan keputusan di Divisi Tenant Relation Management (TRM) pada PT. Buana Sakti.
6
7
BAB II TINJAUAN PUSTAKA
2.1 Key Performance Indicator ( KPI ) Dalam rangka untuk dapat membangun dan meningkatkan kinerja dalam proses, menurut Anupindi (2006) penting untuk mengukur sesuatu / hal yang mungkin untuk diukur. Alfred Sloan, CEO General Motors antara 1923 dan 1946, mendefinisikan pemimpin profesional sebagai salah satu yang mengontrol dengan fakta dari pada intuisi dan emosi. Dengan mengumpulkan fakta-fakta untuk suatu tujuan, sangatlah mungkin untuk mendapatkan pandangan yang jelas dari suatu proses.
Mengukur
kinerja
merupakan
bagian
penting
ketika
mengimplementasikan metode untuk meningkatkan produk dan proses dan juga saat membuat hasil dari sebuah perubahan. (Anupindi 2006 ; diacu dalam Rensfelt, Winblad, Lindman, 2008)
2.1.1 Ukuran Kinerja ( Performance Measures) Ukuran kinerja dapat didefinisikan dalam beberapa cara. Definisi berikut ini disarankan oleh Parmenter (2007) yang dibagi atas 3 Performance Measures, Key Result Indicator (KRI), Key Performance Indicator (KPI) dan Performance Indicator (PI). Dapat dilihat pada Gambar 1.
Gambar 1 Tiga Jenis Ukuran Kinerja (Parmenter 2007) Key Result indicator (KRI) mengukur kinerja dari sudut pandang eksternal, dapat berupa ukuran financial. KRI dimaksudkan untuk memberikan informasi seperti keuntungan bagi para pemegang saham suatu perusahaan. ukuran KRI mengindikasikan apakah arah dari perusahaan telah tepat dan akurat, tetapi tidak
8
memberikan suatu informasi bagaimana meningkatkan hasil yang di dapat. Secara luas KRI mencakup periode yang lebih lama, biasanya bulan, tahun dan sangat tepat untuk manajemen sebagai dasar pengambilan keputusan, tetapi sangat sedikit sekali digunakan untuk aktivitas rutin (Parmenter 2007). Performance Indicator (PI) merupakan indikator yang menunjukan apa yang perlu dicapai dalam pandangan internal operasional perusahaan untuk meningkatkan performa perusahaan. PI merupakan suatu pertimbangan penting sebagai ukuran tambahan dalam KPI ketika pengambilan keputusan. Key
Performance
Indicator
(KPI)
merupakan
indikator
yang
memperlihatkan apa yang perlu dicapai dalam pandangan internal operasional perusahaan. KPI fokus sebagai bagian dari suatu ukuran perusahaan / organisasi yang merupakan suatu hal yang penting untuk menuju sukses baik itu untuk sekarang dan masa depan. KPI yang baik mencerminkan beberapa faktor sukses yang penting dan juga digunakan oleh jenis KPI lainnya.
Parmenter (2007)
mengidentifikasi 7 karakteristik KPI : 1. Ukuran Non Financial 2. Ukuran yang sering digunakan (Regular measurements) 3. Ukuran yang diketahui oleh manajemen 4. Semua orang yang ada di dalam suatu organisasi telah mengerti dan memahami KPI 5. Tanggung jawab kepada individu dan tim 6. Memiliki efek yang sangat signifikan 7. Memiliki efek yang positif Key performance indicator terletak lebih detail di dalam suatu organisasi dan akan di ukur dalam periode harian, mingguan dan bulanan. KPI yang baik merupakan suatu hal yang penting dan terus menerus mendapat perhatian dari manajemen. Ketika telah menyimpang dari tujuan, pihak manajemen dapat mengambil suatu keputusan dan memanggil seseorang yang bertanggung jawab.
2.1.2 Implementasi KPI Parmenter (2007) menyebutkan terdapat 4 kriteria dasar yang harus dipenuhi sebelum suatu organisasi dapat menyatakan bahwa mereka telah
9
mengimplementasikan KPI ke dalam aktivitas operasional. Kriteria tersebut adalah : 1. Kolaborasi antara karyawan, tim, supplier dan pelanggan 2. Desentralisasi dari level manajemen sampai level operasional 3. Integrasi atau keterkaitan antara ukuran, laporan dan tindakan 4. Hubungan KPI ßà strategi Untuk mengimplementasikan KPI, membutuhkan suatu proses sistem yang saling terkait, baik itu dari lingkungan organisasi sendiri seperti karyawan, manager, pemegang saham dan dari pihak-pihak luar seperti pelanggan dan supplier. Parmenter menitik beratkan kepada laporan yang harus tepat waktu, efisien, dan fokus terhadap peningkatan pengambilan keputusan. Ketika
mengimplementasikan
KPI,
hal
yang
penting
adalah
mendefinisikan hasil/tujuan dari masing-masing KPI. Shahin and Mahbod (2007, diacu dalam Rensfelt, Winblad, Lindman, 2008) menyatakan, bahwa SMART merupakan suatu metoda yang menggunakan beberapa kriteria untuk bagaimana merencanakan
suatu
tujuan.
SMART
merupakan
Spesific,
Measurable,
Achievable, Realistic dan Time Sensitive.
Gambar 2 Menggambarkan Penetapan Tujuan SMART (Shahin dan Mahbod, 2007) •
Spesific – Tujuan / hasil haruslah jelas dan spesifik, tujuan / hasil yang melebar sangat tidak diharapkan. Ketika tujuan / hasil jelas dan spesifik, sangat mudah diketahui kapan tujuan / hasil tersebut telah di capai.
10
•
Measurable – Tujuan / hasil harus dapat diukur, baik itu secara kualitas ataupun kuantitas. Hal ini dapat ditempatkan dalam hubungannya dengan performa standar atau harapan dari suatu performa.
•
Achievable – Dapat dicapai, tetapi harus diformulasikan sebagai suatu tantangan dan dengan demikian akan menginspirasi organisasi untuk mencapai hasil / tujuan.
•
Realistic – menciptakan suatu ide yang merupakan hasil / tujuan haruslah tercapai, tetapi harus juga realistis dan berorientasi hasil.
•
Time Sensitive – setiap hasil / tujuan memiliki batasan waktu kapan tujuan / hasil tersebut dapat dicapai. Fakta bahwa tujuan / hasil merupakan sesuatu yang membutuhkan batasan waktu akan membuat suatu kemudahan dalam mengukur suatu peningkatan suatu tujuan/hasil berikutnya.
2.2 Unified Modeling Language (UML) Metode Unified Modeling language ( UML ) adalah suatu modeling analisa yang berorientasi object yang dapat digunakan sebagai salah satu alternatif metode analisa suatu sistem perangkat lunak yang didalamnya terdapat prosesproses yang sesuai dengan kaidah-kaidah pengembangan sistem. UML adalah sebuah bahasa yang berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis Object-Oriented (OO). UML sendiri juga memberikan standar penulisan sebuah sistem blueprint, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan komponen-komponen yang diperlukan dalam sistem software. Pendekatan analisa dan rancangan dengan menggunakan model OO mulai diperkenalkan sekitar pertengahan 1970 hingga akhir 1980 dikarenakan pada saat itu aplikasi software sudah meningkat dan mulai komplek. Jumlah yang menggunakan metoda OO mulai diujicobakan dan diaplikasikan antara 1989 hingga 1994, seperti halnya oleh Grady Booch dari Rational Software Co., dikenal
11
dengan Object-Oriented Software Engineering (OOSE), serta James Rumbaugh dari General Electric, dikenal dengan Object Modelling Technique (OMT). Kelemahan saat itu disadari oleh Booch maupun Rumbaugh adalah tidak adanya standar penggunaan model yang berbasis OO, ketika mereka bertemu ditemani rekan lainnya Ivar Jacobson dari Objectory mulai mendiskusikan untuk mengadopsi masing-masing pendekatan metoda OO untuk membuat suatu model bahasa yang uniform / seragam yang disebut UML dan dapat digunakan oleh seluruh dunia. Secara resmi bahasa UML dimulai pada bulan oktober 1994, ketika Rumbaugh bergabung Booch untuk membuat sebuah project pendekatan metoda yang uniform/seragam dari masing-masing metoda mereka. Saat itu baru dikembangkan draft metoda UML version 0.8 dan diselesaikan serta di release pada bulan oktober 1995. Bersamaan dengan saat itu, Jacobson bergabung dan UML tersebut diperkaya ruang lingkupnya dengan metoda OOSE sehingga muncul release version 0.9 pada bulan Juni 1996. Hingga saat ini sejak Juni 1998 UML version 1.3 telah diperkaya dan direspons oleh Object Management Group (OMG), Anderson Consulting, Ericsson, Platinum Technology, ObjectTime Limited, dll serta di pelihara oleh OMG yang dipimpin oleh Cris Kobryn. UML adalah standar dunia yang dibuat oleh OMG, sebuah badan yang bertugas mengeluarkan standar-standar teknologi objectoriented dan software component. UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan kata-kata dalam ‘Microsoft Word’ untuk kegunaan komunikasi. Sebuah bahasa model adalah sebuah bahasa yang mempunyai vocabulary dan konsep tatanan / aturan penulisan serta secara fisik mempresentasikan dari sebuah sistem. Seperti halnya UML adalah sebuah bahasa standar untuk pengembangan sebuah software yang dapat menyampaikan bagaimana membuat dan membentuk modelmodel, tetapi tidak menyampaikan apa dan kapan model yang seharusnya dibuat yang merupakan salah satu proses implementasi pengembangan software. UML tidak hanya merupakan sebuah bahasa pemograman visual saja, namun juga dapat secara langsung dihubungkan ke berbagai bahasa pemograman, seperti JAVA, C++, Visual Basic, atau bahkan dihubungkan secara langsung ke dalam sebuah object-oriented database. Begitu juga mengenai pendokumentasian dapat
12
dilakukan seperti; requirements, arsitektur, design, source code, project plan, tests, dan prototypes. Untuk dapat memahami UML membutuhkan bentuk konsep dari sebuah bahasa model dan mempelajari 3 (tiga) elemen utama dari UML seperti building block, aturan-aturan yang menyatakan bagaimana building block diletakkan secara bersamaan dan beberapa mekanisme umum (common). 2.2.1 Konsepsi Dasar UML Abstraksi konsep dasar UML yang terdiri atas structural classification, dynamic behavior dan model management dari Diagrams. Main concepts bisa di pandang sebagai term yang akan muncul pada saat diagram dibuat. Dan view adalah kategori dari diagram tersebut (Dharwiyanti dan Wahono, 2003 ). UML mendefinisakan diagram sebagai berikut : • • • • • • • •
use case diagram class diagram statechart diagram activity diagram sequence diagram collaboration diagram component diagram deployment diagram
1. Use Case Diagram Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat sangat membantu bila sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien dan merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan
13
dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common. Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.
2. Class Diagram Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metode/fungsi). Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Class memiliki tiga area pokok : 1. Nama (dan stereotype) 2. Atribut 3. Metode Atribut dan metode dapat memiliki salah satu sifat berikut : • Private, tidak dapat dipanggil dari luar class yang bersangkutan • Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anakanak yang mewarisinya • Public, dapat dipanggil oleh siapa saja Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time. Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package. Hubungan Antar Class 1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus
14
mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class. 2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”). 3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga pewarisan disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi. 4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.
3. Activity Diagram Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi dan bagaimana alur sistem berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan perilaku internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat
untuk
menggambarkan
aktivitas.
Decision
digunakan
untuk
menggambarkan prilaku pada kondisi tertentu. Untuk mengilustrasikan prosesproses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.
15
4. Sequence Diagram Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atas dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message. Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity.
2.3 Sistem Pendukung Pengambilan Keputusan – Decision Support Systems (DSS) Sistem pendukung pengambilan keputusan (DSS) adalah sistem berbasis komputer yang interaktif, yang membantu para pengambil keputusan untuk menggunakan data dan berbagai model untuk memecahkan masalah-masalah yang tidak terstruktur. (Gorry dan Morton, 1978 diacu dalam Turban, Aronson, Liang, 2005). Littel (1970) menyatakan bahwa untuk sukses, sistem tersebut haruslah sederhana, cepat, mudah dikontrol, adaptif, lengkap dengan isu-isu penting dan mudah berkomunikasi. Sistem pendukung ini membantu pengambilan keputusan manajemen dengan menggabungkan data, model-model dan alat-alat analisis yang komplek, serta perangkat lunak yang akrab dengan tampilan pengguna ke dalam satu sistem yang memiliki kekuatan besar (powerful) yang dapat mendukung pengambilan keputusan yang semi atau tidak terstruktur. DSS menyajikan kepada pengguna satu perangkat alat yang fleksibel dan memiliki kemampuan tinggi untuk analisis
16
data penting. Dengan kata lain, DSS menggabungkan sumber daya intelektual seorang individu dengan kemampuan komputer dalam rangka meningkatkan kualitas pengambilan keputusan. DSS diartikan sebagai tambahan bagi para pengambil keputusan, untuk memperluas kapabilitas, namun tidak untuk menggantikan pertimbangan manajemen dalam pengambilan keputusannya. (Sutono, 2007) Turban (2005), mengidentifikasi karakteristik dan kapabilitas kunci dari DSS adalah : 1. Dukungan
untuk
pengambilan
keputusan,
terutama
pada
situasi
semiterstruktur dan tak terstruktur, dengan menyertakan penilaian manusia dan informasi terkomputerisasi. 2. Dukungan untuk semua level manajerial, dari eksekutif puncak sampai manajer lini. 3. Dukungan untuk individu dan kelompok. 4. Dukungan untuk keputusan independen dan atau sekuensial. 5. Dukungan di semua fase proses pengambilan keputusan : inteligensi, desain, pilihan dan implementasi. 6. Dukungan di berbagai proses dan gaya pengambilan keputusan. 7. Adaptive sepanjang waktu. 8. Pengguna merasa seperti di rumah. 9. Peningkatan terhadap keefektifan pengambilan keputusan (akurasi, timeliness, kualitas) ketimbang pada efisiensinya (biaya pengambilan keputusan). 10. Kontrol penuh oleh pengambilan keputusan terhadap semua langkah proses pengambilan keputusan dalam memecahkan suatu masalah. 11. Pengguna akhir dapat mengembangkan dan memodifikasi sendiri sistem sederhana. 12. Biasanya model-model digunakan untuk menganalisis situasi pengambilan keputusan. 13. Akses disediakan untuk berbagai sumber data, format dan tipe, mulai dari sistem informasi geografis (GIS) sampai sistem berorientasi objek.
17
14. Dapat dilakukan sebagai alat standalone yang digunakan oleh seorang pengambil keputusan pada satu lokasi atau didistribusikan di dan di satu organisasi keseluruhan dan di beberapa organisasi sepanjang rantai persediaan. Dalam suatu penelitiannya Alter mengembangkan satu taksonomi dari enam jenis DSS yang didasarkan pada tingkat dukungan pemecahan masalah. Keenam jenis tersebut tampak pada Gambar 3. Tingkat Dukungan Pemecahan Masalah
Sedikit
Tingkat kerumitan sistem
Sangat
Gambar 3 Keenam Jenis DSS Didasarkan Tingkat Dukungan Pemecahan Masalah Jenis DSS yang memberikan dukungan paling sedikit adalah jenis yang memungkinkan manajer mengambil hanya sebagian kecil informasi (unsur-unsur informasi) seperti terlihat pada kolom 1 Gambar 3. Manajer dalam hal ini dapat bertanya pada database untuk mendapatkan angka/jumlah tingkat penyerapan anggaran pada satu satker di bawah lingkup kerjanya. Jenis DSS yang memberikan dukungan yang sedikit lebih tinggi memungkinkan baginya menganalisis seluruh isi file mengenai tingkat penyerapan anggaran pada unit-unit lain yang terkait. Contohnya adalah laporan gaji bulanan pegawai yang disiapkan dari file gaji. Dukungan yang lebih lagi diberikan oleh sistem yang menyiapkan laporan total penyerapan anggaran biaya pegawai dan tunjangan-tunjangan yang diterimanya yang diolah dari berbagai file sistem penggajian. Ada dua tipe DSS yang dikenal, yaitu : Model-driven DSS dan Datadriven DSS. Jenis DSS yang pertama merupakan suatu sistem yang berdiri sendiri terpisah dari sistem informasi organisasi secara keseluruhan. DSS ini sering dikembangkan langsung oleh masing-masing pengguna dan tidak langsung dikendalikan dari divisi sistem informasi. Kemampuan analisis dari DSS ini umumnya dikembangkan berdasarkan model atau teori yang ada dan kemudian
18
dikombinasikan dengan tampilan pengguna yang membuat model ini mudah untuk digunakan. Jenis DSS yang kedua, data-driven DSS, menganalisis sejumlah besar data yang ada atau tergabung di dalam sistem informasi organisasi. DSS ini membantu untuk proses pengambilan keputusan dengan memungkinkan para pengguna untuk mendapatkan informasi yang bermanfaat dari data yang tersimpan di dalam database yang besar. Banyak organisasi atau perusahaan mulai membangun DSS ini untuk memungkinkan para pelanggannya memperoleh data dari website-nya atau data dari sistem informasi organisasi yang ada. Decision Support Systems meliputi berbagai komponen yang termuat di dalam sistem pendukung ini, yaitu : • DSS database: Kumpulan data berjalan atau historis dari sejumlah aplikasi. Komponen ini digunakan untuk menanyakan dan menganalisis data. Database ini dapat berupa PC database atau massive database. • DSS software Systems: Kumpulan dari perangkat lunak yang digunakan untuk menganalisis data, seperti: On-Line Analytical Processing (OLAP) tools, datamining tools, atau kumpulan dari model-model matematika dan analisa yang mudah untuk diakses oleh para pengguna DSS. Model ini dapat berupa model fisik (model rancangan ruang kerja, taman, dan model pesawat terbang), model perhitungan matematika (seperti : persamaan, alogaritma, anuitas, cicilan bunga kredit), atau model verbal (seperti : deskripsi suatu prosedur untuk penulisan suatu perintah kerja/order). Masingmasing DSS dibangun untuk seperangkat tujuan tertentu dan akan menghasilkan berbagai kumpulan model tergantung pada kebutuhan dan tujuannya. Aplikasi DSS dapat terdiri dari subsistem seperti : 1. Subsistem Manajemen Data Subsistem manajemen data memasukkan satu database yang berisi data yang relevan untuk situasi dan dikelola oleh perangkat lunak yang disebut sistem manajemen database (DBMS). Subsistem manajemen data dapat diinterkoneksikan dengan data warehouse perusahaan, suatu repositori untuk data perusahaan yang relevan untuk pengambilan keputusan. 2. Subsistem Manajemen Model
19
Merupakan paket perangkat lunak yang memasukkan model keuangan, statistik, ilmu manajemen atau model kuantitatif lainnya yang memberikan kapabilitas analitik dan manajemen perangkat lunak yang tepat. Perangkat lunak ini sering disebut sistem manajemen basis model (MBMS). 3. Subsistem antarmuka pengguna Pengguna berkomunikasi dengan dan memerintahkan DSS melalui subsistem ini. Para peneliti menegaskan bahwa beberapa kontribusi unik dari DSS berasal dari interaksi yang intensif antara komputer dan pembuat keputusan. 4. Subsistem Manajemen Berbasis Pengetahuan Subsistem ini dapat mendukung semua subsistem lain atau bertindak sebagai suatu komponen independen. Susbsistem ini memberikan inteligensi untuk memperbesar pengetahuan orang pengambil keputusan. Subsistem ini dapat diinterkoneksikan dengan repositori pengetahuan perusahaan (bagian dari sistem manajemen pengetahuan), yang kadangkadang disebut basis pengetahuan organisasional. Berdasarkan definisi, DSS harus mencakup tiga komponen utama dari DBMS, MBMS dan antarmuka pengguna. Subsistem manajemen berbasis pengetahuan adalah opsional, namun dapat memberikan banyak manfaat karena memberikan inteligensi bagi tiga komponen utama tersebut. Seperti pada semua sistem informasi manajemen, pengguna dapat dianggap sebagai komponen DSS. 2.4 Penelitian Sebelumnya yang Relevan Valverde
(2011)
melakukan
penelitian
dengan
membuat
DSS
Manajemen resiko untuk industri real estate. Pada penelitian tersebut sistem informasi dirancang sesuai dengan spesifikasi dan diimplementasikan dengan menggunakan bahasa pemrograman Visual Basic dan database Microsoft Access. Database sistem itu diisi dengan data dari California USA dan sistem diuji dengan contoh-contoh berbeda dan laporan yang memuaskan diperoleh dari simulasi. DSS sangatlah berguna bagi manager manajemen resiko dalam investasi real estate. DSS dapat dideskripsikan sebagai sebuah interaksi, berbasis sistem komputer yang di desain untuk membantu pengambil keputusan untuk
20
menyelesaikan masalah yang tidak terstruktur. Pengguna utama dari sistem ini adalah investor untuk memonitor kinerja dari pengelola gedung. Tujuan sistem akan memberikan informasi mengenai hal-hal sebagai berikut : o
Berapa kategori aset yang akan digunakan
o
Memilih optimasi level resiko keseluruhan
o
Kapan waktunya untuk melakukan penjualan aset
o
Nilai dari properti
Mohemad, Hamdan, Othman dan Noor (2010) melakukan penelitian dalam membuat suatu keputusan yang transparan dan persaingan yang sehat dalam proses tender membutuhkan suatu alat sebagai dasar panduan dalam proses pengambilan keputusan. Makalah ini menyimpulkan hal-hal yang biasa digunakan dalam proses tender secara umum di dunia seperti Amerika, Eropa dan Asia. Dokumen terstruktur dalam jumlah yang banyak dalam proses tender konstruksi perlu di analisa dengan alat komputasi. Akan menjadi lebih sulit ketika proses otomatisasi untuk perubahan dokumen tidak struktur ke dalam format atau bentuk dokumen terstruktur pada proses input di dalam proses pengambilan keputusan. Dalam rangka untuk melakukan proses tender secara otomatis, integrasi di dalam model DSS sepertinya pendekatan model yang menjanjikan. Makalah ini mengusulkan sebuah kerangka kerja untuk DSS dalam tujuannya untuk melakukan pengembangan proses tender. Cai, Liu X., Xiao dan Liu J. (2009) melakukan penelitian dalam strategi peningkatan kinerja untuk pembuat keputusan dalam dunia supply chain. • KPI pada bisnis supply chain menjadi isu yang penting untuk meningkatkan kinerja secara berkelanjutan • Sistem kinerja manajemen yang kompleks meliputi beberapa proses manajemen,
seperti
identifikasi
ukuran,
menentukan
target,
perencanaan, komunikasi, monitoring, laporan dan masukan • Peningkatan kinerja merupakan proses yang terus menerus yang membutuhkan baik itu analisa ukuran kinerja sistem dan mekanisme untuk memulai langkah-langkah untuk mewujudkan tujuan KPI (Pencapaian KPI) yang berhubungan dengan perencanaan dan
21
pelaksanaan, dan membuat langkah-langkah untuk merealisasikan tujuan kinerja dalam pekerjaan rutin sehari-hari. Metodologi yang diusulkan untuk meningkatkan kinerja
manajeman
Supply Chain secara sistematik adalah metodologi yang mendukung KPI accomplishment (Pencapaian KPI). Metodologi ini mengimplementasikan pengulangan yang lebih kecil diatara 3 langkah utama dalam siklus kinerja manajemen yaitu Set Goal, Model dan Plan. Penentuan metodologi untuk pembahasan ini adalah Supply Chain Operation Reference (SCOR) merupakan model yang didesain untuk memfasilitasi kerangka dari ukuran kinerja supply chain secara sistematik dan sebagai alat untuk pengembangan selanjutnya. SCOR memiliki 5 kategori pengukuran yaitu : Sumber daya, Keluaran, Fleksibilitas, Inovasi dan Informasi. Sistematik Metodologi KPI : 1. Balance Score Card (BSC) 2. Activity Based Costing (ABC) 3. Supply Chain Operation Reference (SCOR) Roy, Chamorro, Wegen dan Steele melakukan penelitian membuat solusi yang diusulkan dalam makalah ini menyediakan mekanisme untuk pemantauan solusi Knowledge Management (KM) dalam isu-isu terkait dengan proses bisnis. Metodologi baru ini difokuskan pada tujuan bisnis untuk membuat solusi indikator kinerja (PI) KM. Sistem pengukuran harus dipelajari adalah : • Langkah-langkah kinerja individu • Himpunan ukuran kinerja secara keseluruhan • Hubungan antara kinerja sistem pengukuran dan lingkungan dimana KM beroperasi Penelitian ini telah mengembangkan 'langkah demi langkah' kerangka kerja dan pendekatan metodologis untuk mengidentifikasi Key Performance Indicator (KPI) untuk solusi KM. Para konseptual menghubungkan kerangka pengukuran strategis untuk KM solusi pada tingkat operasional. Pendekatan metodologis memberikan praktisi dengan menetapkan template yang tepat dalam membantu manajer untuk melaksanakan kerangka konseptual. KPI yang dikembangkan dengan ukuran kerangka efektivitas solusi KM dalam proses bisnis, yang memungkinkan perusahaan untuk tidak hanya memantau jika
22
pengetahuan dikelola benar tetapi juga jika hak pengetahuan dikelola dalam perusahaan.
2.5 Perbedaan Penelitian dengan Penelitian Sebelumnya Dari uraian di atas dan tujuan dari penelitian yang akan dikembangkan, dapat dilihat perbedaannya. Seperti terlihat pada Tabel 1 di bawah ini : Tabel 1. Perbedaan Penelitian yang dikembangkan dengan penelitian sebelumnya. Penelitian Sebelumnya Nama Peneliti
Metode yang digunakan, Objek dari penelitian, Topik Tools dan Bentuk yang dihasilkan
Valverde, 2011
Model matematika (Findaly Model, Tucker Model), industri real estate, metode DSS untuk hasil yang di capai, tools Visual Basic dan database Microsoft Acces, menghasilkan Aplikasi manajemen resiko real estate
Mohemad, Hamdan, Proses tender di bidang konstruksi, metode DSS dan hasil Othman dan Noor, berupa kerangka kerja 2010 Cai, Liu X., Xiao Supply Chain Operation Reference (SCOR), supply dan Liu J., 2009
chain., berdasarkan KPI accomplishment dan hasil berupa kerangka kerja
Roy,
Chamorro, Knowledge
Wegen dan Steele
Management
(KM),
proses
berdasarkan KPI dan hasil berupa kerangka kerja
bisnis,
23
Penelitian yang dikembangkan Husna, 2012
Metode Waterfall untuk penelitian, Divisi TRM di Manajemen properti, Analisis dan desain rancangan menggunakan UML, implementasi menggunakan Power Builder 11.5 dan database engine SQL Anywhere 8, hasil berupa aplikasi menghasilkan report DSS berbasis KPI
24
25
BAB III METODE PENELITIAN
3. 1 Kerangka Pemikiran Kebutuhan akan suatu laporan key performance indicator yang cepat dan tepat merupakan suatu hal yang sangat penting agar mampu menghasilkan sejumlah informasi yang bermanfaat bagi manager dalam proses pengambilan keputusan atas aktivitas yang terjadi pada divisi Tenant Relation management. Kondisi saat ini mengharuskan Divisi Tenant Relation management untuk melakukan rekapitulasi secara manual ataupun secara sistem yang berbeda untuk membuat suatu laporan KPI. Hal ini membutuhkan waktu yang lama hanya untuk mengeluarkan suatu laporan dan tidak secara real time. Situasi tersebut akan terus berulang setiap akan terbitnya laporan yang secara biaya akan bertambah dan akan mengurangi efektivitas dan efisiensi kerja dari karyawan. Guna mencapai kebutuhan tersebut pengembangan suatu sistem informasi perangkat lunak yang terintegrasi sangatlah dibutuhkan. Dengan Pengembangan Aplikasi Decision Support Systems berbasis KPI ini dapat mengatasi segala permasalahan yang timbul pada divisi Tenant Relation Management saat ini sehingga akan memberikan gambaran apa saja target yang tidak tercapai.
3. 2 Kerangka Penelitian Dalam mencapai kerangka pemikiran di atas, hal yang perlu dilakukan adalah memahami kondisi dan masalah yang ada dengan menuangkannya ke dalam suatu metodologi kerja menggunakan metode waterfall (Sommerville, 2011) dengan memberikan suatu solusi atas permasalahan di divisi Tenant Relation management tersebut. Tahapan-tahapan yang dilakukan dalam penelitian ini menghasilkan pengembangan Decision Support Systems yang berbasiskan key performance indicator. Pada penelitian ini dilakukan penggunaan parameterparameter key performance indicator yang sudah diformulasikan oleh para direksi divisi Tenant Relation Management. Untuk kerangka penelitian yang dilakukan dapat dilihat pada Gambar 4.
26
Mulai
Studi kebutuhan Kesalahan Prosedur / Proses Bisnis Identifikasi Masalah
Analisis Kebutuhan Sistem
Proses Bisnis
Bukan
Desain Sistem
Ya
Implementasi Sistem
Ada Kesalahan
Pengujian Sistem
Tidak
Analisis Output
Selesai
Gambar 4 Kerangka Penelitian Berikut penjelasan mengenai tahapan kerangka penelitian : a. Studi Kebutuhan (Requirement Study) Analisis kebutuhan merupakan suatu tahapan dalam pengembangan perangkat lunak untuk menggali segala bentuk informasi dari awal sampai akhir dengan harapan dapat mengetahui kendala-kendala yang dihadapi. Pada tahapan ini akan digunakan untuk melakukan interview / tanya jawab
27
mengenai kondisi yang ada sekarang dan masalah yang dihadapi dengan kondisi yang ada beserta harapan untuk memperbaharui kondisi yang ada. 1. Requirement Scope (Batasan Sistem) 2. Stakeholder Identification (Identifikasi Entitas) Stakeholder Identification merupakan entitas yang akan terlibat dalam sistem divisi Tenant Relation Management. Proses ini merupakan tahapan yang penting dalam proses penyusunan UML. 3. Requirement Gathering (Pengumpulan Informasi) Berdasarkan informasi entitas yang terlibat dalam sistem divisi Tenant Relation Management, proses pengumpulan informasi akan dilakukan untuk masing-masing entitas baik itu proses yang biasa dilakukan dan harapan yang diinginkan sampai dengan konsep pelaporan. Dalam pembahasan ini akan dibatasi untuk transaksi-transaksi yang berhubungan dengan departemen-departemen di bawah divisi Tenant Relation Management. b. Identifikasi Masalah Pada tahapan ini akan diidentifikasi beberapa permasalahan yang ada pada divisi Tenant Relation Management dan identifikasi kebutuhan informasi yang mendukung pengembangan Decision Support Systems yang berbasiskan key performance indicator baik itu merupakan perbaikan dari sistem yang lama ataupun penambahan suatu proses bisnis yang semakin maju. Pengidentifikasian masalah ini terjadi selama masa interview / tanya jawab. c. Analisis Kebutuhan Sistem Dalam proses menganalisa kebutuhan sistem, perlu dilakukan analisis berdasarkan studi pustaka dan literatur mengenai konsep key performance indicator yang dibutuhkan selama penelitian. Oleh karena itu analisa kebutuhan harus mencakup sebagian besar proses yang berkaitan dengan divisi Tenant Relation Management (TRM). Hasil dari studi kebutuhan dan identifikasi masalah akan diterjemahkan menjadi suatu proses-proses dengan metode yang berorientasi object (UML). Analisis kebutuhan sistem ini akan dibuatkan analisis menggunakan deskripsi use case, use
28
case diagram, activity diagram, class diagram dan sequence diagram untuk input, output, proses, storage dan kontrol. d. Desain Sistem Dalam proses ini, dilakukan proses desain sistem divisi Tenant Relation Management berdasarkan analisis yang ada diterjemahkan menjadi desain sistem suatu proses-proses dengan metode yang berorientasi object (UML), baik itu dari sisi logika bisnis, struktur data maupun Graphical User Interface (GUI). Dalam tahapan ini perangkat lunak apa yang akan digunakan untuk pengembangan Decision Support Systems yang berbasiskan Key Performance Indicator. e. Implementasi Sistem Proses penerapan analisis dan desain sistem baik itu logika dan tampilan (Graphical User Interface) dengan menggunakan perangkat lunak pengembangan sistem Power Builder 11.5 dan database engine SQL Anywhere 8 yang menghasilkan Pengembangan DSS berbasis KPI sebagai bentuk akhir laporan KPI buat manajer atau manajemen. f. Pengujian Sistem Proses pengujian sistem secara internal dapat dilakukan baik itu secara verifikasi ataupun validasi data dan disesuaikan dengan parameter KPI yang ada dilakukan guna mengantisipasi seminimal mungkin pengujian yang gagal ketika dilakukan test oleh user. Metode pengujian yang diambil adalah metode pengujian Black Box. Pengujian Black Box adalah pengujian aspek fundamental sistem tanpa memperhatikan struktur logika internal perangkat lunak. Metode ini digunakan untuk mengetahui apakah perangkat lunak berfungsi dengan benar. g. Analisis Output Analisis output laporan KPI dilakukan ketika hasil yang dikeluarkan dari sistem tidak memenuhi kriteria estetika dan aturan standar dari pihak divisi Tenant Relation Management.
29
BAB IV PEMBAHASAN PENGEMBANGAN DECISION SUPPORT SYSTEMS BERBASIS KEY PERFORMANCE INDICATOR DI DIVISI TENANT RELATION MANAGEMENT
4.1. Studi Kebutuhan 4.1.1. Kondisi Divisi Tenant Relation Management Saat ini Laporan KPI merupakan laporan yang sangat penting bagi divisi Tenant Relation Management untuk landasan dalam pengambilan keputusan yang berpengaruh terhadap 3 departemen di bawahnya, yaitu : a. Departemen Tenancy b. Departemen Marketing & Leasing c. Departemen Customer Service Secara garis besar, semua informasi yang digunakan dalam melakukan proses formulasi KPI sudah tersedia dalam dokumentasi general manager, tapi sistem yang selama ini digunakan belum terintegrasi antar ketiga departemen baik laporan KPI maupun formula KPI belum termasuk dalam sistem, sehingga mengakibatkan formulasi KPI tersebut belum dilakukan dengan baik dan benar. Laporan KPI merupakan salah satu elemen dari laporan divisi TRM. Laporan KPI harus tersedia setiap bulannya yang digunakan sebagai informasi kinerja divisi tersebut dihadapan manajemen. Laporan KPI dari divisi TRM berisi berbagai macam informasi mengenai aktivitas-aktivitas yang dilakukan oleh personil / karyawan di Divisi TRM, seperti service level penanganan keluhan, persentase nilai hunian dan lain-lain. Laporan KPI yang ada sekarang di divisi Tenant Relation Management masih dilakukan secara sistem yang tidak terintegrasi, dengan menggabungkan informasi masing-masing departemen dengan menggunakan laporan Microsoft Excell. Kecepatan pembuatan laporan yang berbasis KPI sangatlah dibutuhkan oleh divisi TRM untuk pelaporan kepada pihak manajemen. Berdasarkan hasil penelitian yang dilakukan di lokasi, terdapat beberapa harapan manajemen terhadap pengembangan KPI sebagai salah satu faktor peningkatan kinerja perusahaan, harapan-harapan tersebut adalah sebagai berikut :
30
a.
Mengetahui secara real time total jumlah keluhan/permintaan setiap bulannya.
b.
Mengetahui secara real time persentase keluhan yang sudah terselesaikan dan belum terselesaikan per minggunya.
c.
Mengetahui secara cepat dan tepat persentasi kategori tenant (Platinum, gold dan silver).
d.
Mengetahui secara global total luasan yang masing available / tersedia untuk disewakan (net lettable area).
e.
Mengetahui nilai occupancy rate / persentase hunian secara real time.
f.
Mengetahui rata-rata harga sewa / m2 per bulan.
g.
Mengetahui secara cepat dan tepat tenant-tenant yang akan habis masa kontraknya dalam periode minimal 1 tahun sebelum masa kontrak tersebut habis.
h.
Mengetahui informasi sisa budget TRM yang digunakan sebagai kontrol terhadap proses pembelian yang dilakukan oleh divisi TRM.
i.
Mengetahui informasi pendapatan atas event (pameran, pernikahan, bazaar) secara real time per bulan beserta target pendapatan yang harus dicapai. Dengan adanya laporan KPI, terpenuhinya harapan manajemen dalam membantu memberikan suatu pandangan dan pengambilan keputusan buat manager di divisi Tenant Relation Management.
4.1.2. Sistem Divisi Tenant Relation Management di Bidang Properti Divisi Tenant Relation Management merupakan pintu masuk hubungan antara manajemen gedung dan pihak luar, baik itu tenant ataupun non tenant. Secara garis besar divisi Tenant Relation Management terdiri atas 3 departemen, yaitu : a.
Departemen Tenant Relation
b.
Departemen Customer Service / Call Center
c.
Departemen Marketing
31
Ketiga departemen tersebut secara fungsional memiliki pekerjaan yang saling berhubungan satu sama lain, secara garis besar fungsi atas ketiga departemen tersebut adalah sebagai berikut :
1.
Departemen Tenant Relation Departemen Tenant Relation merupakan departemen yang difungsikan
untuk melakukan hubungan dengan tenant yang ada baik secara langsung maupun tidak langsung. Secara langsung departemen Tenancy akan melakukan beberapa aktivitas yang dapat mempererat hubungan komunikasi antara tenant dan pengelola, secara tidak langsung departemen Tenancy melakukan beberapa aktivitas sosial yang dapat digunakan atau dimanfaatkan oleh semua penghuni yang ada di dalam gedung. Secara garis besar aktivitas dari departemen Tenancy adalah sebagai berikut : •
Melakukan update informasi tenant. Aktivitas ini merupakan proses update data atau informasi penting yang berhubungan dengan tenant dan memiliki efek terhadap departemen lainnya seperti, perubahan nama direksi, perubahan No NPWP, perubahan atau penambahan fasilitas layanan yang disediakan oleh pengelola gedung dan lain sebagainya.
•
Melakukan reguler visit / kunjungan rutin. Aktivitas ini merupakan aktivitas dalam jangka waktu yang sudah ditentukan, dimana setiap tenant akan dilakukan kunjungan oleh pihak manajemen yang dikoordinasikan oleh Departemen Tenancy untuk mendengarkan masukan atau keluhan secara langsung dari tenant tersebut.
•
Melakukan event / acara olahraga. Aktivitas ini merupakan aktivitas rutin tahunan yang dilakukan oleh Departemen Tenancy untuk menjalin hubungan sesama tenant.
•
Melakukan sosialisasi kebijakan atau informasi. merupakan aktivitas yang dilakukan oleh Departemen Tenancy untuk mensosialisasikan informasi yang berhubungan dengan proses sewa menyewa ataupun informasi yang berhubungan dengan layanan-layanan yang disediakan oleh pihak manajemen dari pihak ketiga, seperti informasi jadwal SIM keliling, jadwal donor darah dan lain sebagainya.
32
•
Melakukan pembuatan laporan untuk Departemen Tenancy dengan waktu yang sudah disepakati baik itu untuk harian, mingguan ataupun bulanan yang dikirimkan ke Manager Divisi TRM.
2.
Departemen Customer Service / Call Center Departemen Customer Service merupakan departemen melakukan fungsi
sebagai pintu utama dalam proses permintaan dan keluhan baik itu dari tenant ataupun dari non tenant. Departemen Customer Service melakukan distribusi ke departemen terkait terhadap permintaan atau keluhan yang datang baik itu dari tenant ataupun dari non tenant seperti pengunjung. Secara garis besar aktivitas yang dilakukan oleh Departemen Customer Service adalah sebagai berikut : •
Melakukan penanganan pertama terhadap keluhan dan/atau permintaan. Aktivitas harian yang dilakukan oleh Departemen Customer Service untuk menerima permintaan dan/atau keluhan dari tenant ataupun bukan tenant yang diteruskan ke departemen terkait. Seperti untuk keluhan yang berhubungan dengan fasilitas gedung (lift, AC dan lain-lain), Departemen Customer Service mendistribusikan keluhan tersebut ke Divisi Engineering, kebersihan didistribusikan ke divisi General Affair and Personal, permintaan untuk invoice atau perpanjangan parkir didistribusikan ke divisi Finance and Accounting dan sebagainya.
•
Melakukan registrasi lembur. Aktivitas yang dilakukan oleh Departemen Customer Service untuk melakukan proses pendaftaran lembur yang terdiri dari overtime AC, overtime Lift Service dan overtime listrik yang datang dari tenant ataupun kontraktor. Dimana semua informasi overtime tersebut didistribusikan ke Departemen Control Room (Departemen Operations).
•
Melakukan pembuatan laporan untuk Departemen Customer Service dengan waktu yang sudah disepakati baik itu untuk harian, mingguan ataupun bulanan yang dikirimkan ke Manager Divisi TRM.
3.
Departemen Marketing Departemen Marketing merupakan departemen yang selalu berhubungan
dengan pihak luar (non tenant) yang menjalankan fungsinya sebagai fasilitator
33
terhadap proses penyewaan area yang terdapat dalam gedung. Aktivitas yang dilakukan oleh Departemen Marketing adalah sebagai berikut : •
Melakukan proses prospecting calon tenant. Aktivitas ini merupakan proses mendata calon-calon tenant yang pernah melakukan hubungan dengan pihak marketing untuk penyewaan area kantor. Aktivitas ini berguna bagi pihak marketing ketika melakukan proses penawaran terhadap area yang kosong di kemudian hari.
•
Mempersiapkan dan membuat kontrak sewa. Seluruh kontrak sewa harus dibuat dengan jelas dan memuat seluruh isi perjanjian yang harus ada di dalamnya sehingga tidak menimbulkan potensi konflik di kemudian hari. Misalnya kapan mulai dan berakhirnya suatu kontrak, apa yang menjadi kewajiban dan hak masing-masing pihak, sangsi dan lain sebagainya.
•
Melakukan pemasaran dan negosiasi harga sewa. Aktivitas ini sangat menentukan keberhasilan suatu properti yang di kelola. Dengan kemampuan yang dimiliki diharapkan dapat memaksimalkan tingkat hunian (occupancy rate) dan meminimalisasi tingkat kekosongan (vacancy rate).
•
Melakukan proses renewal / perpanjangan sewa tenant. Aktivitas ini sangatlah berhubungan dengan proses mempertahankan occupancy rate. Aktivitas ini merupakan proses yang harus dilakukan terhadap tenant apabila waktu sewa atas penyewa tersebut akan habis. Dalam proses ini terdapat beberapa perubahan dari sisi kontrak sebelumnya diantaranya adalah : Ø Perubahan terhadap harga sewa Ø Perubahan terhadap harga rental Ø Perubahan masa akhir sewa
•
Proses penambahan security deposit / uang jaminan
•
Melakukan pembuatan laporan untuk Departemen Marketing dengan waktu yang sudah disepakati baik itu untuk harian, mingguan ataupun bulanan yang dikirimkan ke Manager Divisi TRM. Hubungan ketiga departemen tersebut sangat menentukan kinerja dan
peningkatan citra dari pengelolaan gedung di dunia pengelolaan gedung dan properti. Dalam proses peningkatan kinerja divisi TRM terdapat beberapa kendala atau kekurangan yang dihadapi seperti tercantum di dalam identifikasi masalah.
34
Untuk meningkatkan kinerja divisi TRM dengan mengatasi permasalahan dan kendala sehingga cepat dilakukan tindakan oleh Manager, maka diperlukan laporan KPI. Laporan KPI merupakan pengembangan Decision support Systems (DSS) yang berdasarkan dari parameter-parameter KPI yang ada dan sudah diformulasikan oleh manajer divisi TRM. Proses pembuatan laporan KPI ini yang dikembangkan, analisis dan desain dalam penelitian ini.
4.1.3 Key Performance Indicator Tenant Relation Management Systems Parameter KPI yang sudah diformulasikan akan digunakan sebagai pembandingan hasil dari proses laporan KPI pengembangan DSS yang terjadi pada Divisi Tenant Relation Management. Parameter KPI ini dibagi menjadi kelompok faktor internal dan faktor eksternal bagi perusahaan. a.
Faktor Internal KPI faktor internal ini dikelompokan berdasarkan dari kebutuhan atau tujuan
perusahaan dilihat dari segi pendapatan perusahaan atau aspek perekonomian dalam perusahaan. 1. Rata-rata Rental Rate Ø Deskripsi KPI
: Rata-rata Rental Rate untuk setiap bulannya.
Ø Parameter Target : 15 USD Ø Formula
: Rental = Area x RentalRate RR = sum(Rental) / sum(Area) IF RR >= Target Rate (15 USD) Then ‘Achieve’ Else ‘Not Achieve’
Dengan
:
- Rental : Sewa setiap tenant - Area : Area yang di sewa tenant - RentalRate : Harga sewa/m2 - RR : Rata-rata Rental Rate
2. Persentase Occupancy Rate Ø Deskripsi KPI
: Persentase Occupancy rate terhadap total luasan yang di bagi menjadi Platinum , Gold dan Silver.
35
Ø Parameter Target : Platinum 55 %, Gold, 30% dan Silver 15% Ø Formula Dengan
: %OCC= (Sum(Tipe) / NLA)x100% :
- OCC = % Occupancy - Tipe = Masing-masing tipe (Platinum, Gold & Silver) - NLA = Total Area yang dapat disewakan
3. Persentase Letter Of Offer / LOO Ø Deskripsi KPI
: Persentase LOO terhadap total renewal tenant yang habis masa kontraknya.
Ø Parameter Target : 90% LOO Ø Formula
: LOO=(Count(RN)/Count(EX))x 100% IF LOO >= Target Renewal (90 % LOO) Then ‘Achieve’ Else ‘Not Achieve’
Dengan
:
- LOO : % Keberhasilan - RN : Total Renewal - EX : Total tenant renewal
4. Total pendapatan Rental/Sewa dan Event divisi TRM Ø Deskripsi KPI
: Total pendapatan Rental/Sewa per bulan yang
dibandingkan dengan budget pendapatan Rental/Sewa. Achieve jika pendapatan >= budget, Not Achieve jika pendapatan < budget. Total pendapatan event dibandingkan dengan budget yang ada setiap bulannya. Ø Parameter Target : Data Budget untuk total pendapatan sewa per bulan, Budget pendapatan Event di divisi TRM Ø Formula Dengan
: If PA >=PB Then ‘Achieve’ Else ‘Not Achieve’ :
- PA : Pendapatan Actual - PB : Pendapatan Budget
36
5. Total biaya divisi TRM Ø Deskripsi KPI
: Total Biaya divisi TRM dibandingkan dengan budget yang ada setiap bulannya.
Ø Parameter Target : Budget Biaya divisi TRM Ø Formula Dengan
: If BA >=BB Then ‘Not Achieve’ Else ‘Achieve’ :
- BA : Biaya Actual - BB : Biaya Budget
b. Faktor Eksternal KPI faktor eksternal ini dikelompokan berdasarkan dari kebutuhan atau tujuan peningkatan kualitas pelayanan terhadap tenant dilihat dari lebih cepat, lebih baik dalam proses penanganan keluhan dan permintaan tenant atau aspek pelayanan jasa. 6. Persentase total keluhan Ø Deskripsi KPI
: Persentase total keluhan yang terselesaikan.
Ø Parameter Target : 95 % Ø Formula
: %KK=Count(KL)/Count(PL)x100% IF Done Complaint/KK >= Target Complaint Status (95%) Then ‘Achieve’ Else ‘Not Achieve’
Dengan
:
- KK : % keberhasilan - KL : Keluhan selesai (DateTime) - PL : total Keluhan
7. Rata-rata response time terhadap keluhan Ø Deskripsi KPI
: Rata-rata response time terhadap keluhan yang datang dari tenant.
Ø Parameter Target : 15 Menit per keluhan Ø Formula
: Time = RT – KL AvRT = Sum(Time) / Count(KL)
37
IF Avg Complaint Response/AvRT >= Target Complaint Response / Avg Respons (15 minutes) Then ‘Achieve’ Else ‘Not Achieve’ Dengan
:
- RT : Response Time (DateTime) - KL : Keluhan Time (DateTime) - Time : Waktu Response (Time) - AvRT : Average RT (Time)
8. Persentase Inquiry/permintaan Event dan Leasing Ø Deskripsi KPI
: Persentase inquiry / Permintaan Event dan Leasing yang terealisasi berbanding dengan total inquiry yang masuk per bulan.
Ø Parameter Target : 90% Inquiry menjadi Realisasi Ø Formula
: SC=(Count(TR)/count( IQ))x 100% IF Done Inquiry/SC >= Target Inquiry (90%) Then ‘Achieve’ Else ‘Not Achieve’
Dengan
:
- SC : % Keberhasilan - TR : Total Realisasi Inquiry - IQ : Total Inquiry
9. Rata-rata response time terhadap inquiry Ø Deskripsi KPI
: Rata-rata response time terhadap inquiry / permintaan dalam 1 bulan.
Ø Parameter Target : 24 Jam dari inquiry / permintaan masuk Ø Formula
: Time = RT – IQ AvRT = Sum(Time) / Count(IQ) IF Avg Response/AvRT >= Target
Inquiry
Response / Avg Respons (24 jam) Then ‘Achieve’ Else ‘Not Achieve’ Dengan
:
38
- RT : Response Time (DateTime) - IQ : Inquiry (DateTime) - Time : Waktu Response (Time) - AvRT : Average RT (Time)
4.2 Analisis Proses Divisi Tenant Relation Management 4.2.1 Keputusan Manager Divisi Tenant Relation Management Pengembangan Decision Support Systems ini menghasilkan suatu laporan report KPI dari hasil transaksi-transaksi sistem informasi Divisi Tenant Relation Management yang memberikan informasi dan gambaran buat Manager dalam mengambil keputusan dalam : 1. Kapan melakukan review operasional Engineering, House Keeping dan Security dari hasil laporan KPI Call Center untuk transaksi Complaint dan Complaint Response Time. 2. Kapan melakukan review operasional Marketing dari hasil laporan KPI Call Center untuk transaksi Inquiry dan Inquiry Response Time. 3. Hasil laporan KPI Marketing untuk Transaksi Rental Rate dan Occupancy Rate menghasilkan keputusan yang diambil dalam : a. Kapan menentukan kenaikan dan penurunan Service Charge b. Kapan menentukan kenaikan Rental Charge c. Kapan fokus terhadap penjualan area Platinum 4. Kapan Marketing harus mencari tenant baru / Prospecting baru dari hasil laporan KPI Marketing untuk transaksi Renewal. 5. Hasil laporan KPI Expense menghasilkan keputusan untuk perubahan budget tahun depan berdasarkan trend pengeluaran yang over budget pada bulan-bulan tertentu. 6. Hasil laporan KPI Income menghasilkan keputusan untuk perubahan budget income tahun depan berdasarkan trend pendapatan yang di bawah budget pada bulan-bulan tertentu.
39
4.2.2 Identifikasi Pelaku Bisnis Proses identifikasi pelaku bisnis dapat dilakukan pada saat observasi ke lingkungan kerja. Proses identifikasi pelaku dapat memudahkan dalam menyaring dan mendefinisikan lebih lanjut
lingkup dan batasan sistem. Pelaku juga
menentukan kelengkapan persyaratan sistem (Whitten, Bentley dan Dittman, 2004). Dalam penentuan pelaku bisnis dapat diketahui dari hal-hal berikut : 1. Siapa yang menyediakan input kedalam sistem 2. Siapa yang menerima output dari sistem 3. Antarmuka apa yang dibutuhkan bagi sistem yang lain 4. Apakah ada kejadian yang di picu secara otomatis pada waktu yang telah ditentukan sebelumnya 5. Siapa yang akan mengurusi informasi dari sistem. Dalam divisi Tenant Relation Management dapat diidentifikasi pelakupelaku bisnis seperti yang ada di dalam tabel berikut; Tabel 2. Daftar Pelaku-pelaku Bisnis Divisi Tenant Relation Management No 1
Deskripsi Aktivitas
Pelaku Call Centre
Jabatan yang melakukan proses penginputan datadata keluhan dan permintaan baik itu dari tenant ataupun non tenant. Melakukan penginputan permintaan lembur dari tenant dan kontraktor yang melakukan pekerjaan.
2
Marketing Leasing
Jabatan yang melakukan proses prospecting tenant baru,
negosiasi,
perpanjangan
kontrak
dan
melakukan proses letter of offer (LOO) untuk proses tenant baru atau pun perpanjangan kontrak sewa. Merespon semua permintaan dan keluhan yang ditujukan ke departemen marketing leasing. 3
Marketing Event
Jabatan
yang
melakukan
proses
prospecting
terhadap penyewaan ruang-ruang event, negosiasi dan melakukan proses LOO (letter of offer) untuk
40
proses penyewaan ruang-ruang event. Merespon semua permintaan dan keluhan yang ditujukan ke departemen marketing event. 4
Tenancy
Jabatan
yang
bertanggung
perubahan-perubahan
data
jawab dari
terhadap
tenant
dan
mendaftarkan fasilitas-fasilitas apa saja
yang
digunakan oleh tenant. Bertanggung jawab untuk pembuatan permintaan pembelian untuk divisi Tenant Relation Management. 5
Account Recievable
Tanggung jawab organisasi dalam melakukan proses penagihan atas kontrak event ataupun kontrak leasing yang sudah disetujui.
6
Account Payable
Tanggung jawab organisasi dalam melakukan proses pembayaran atas permintaan pekerjaan ataupun barang.
7
Control Room
Bagian yang melakukan proses approval terhadap permintaan lembur.
8
TRM
Manager
General Manager
/ Melakukan proses review terhadap laporan-laporan dari
divisi
Tenant
Relation
Management.
Melakukan entry parameter penentuan target. 9
Tenant
Individu
atau
perusahaan
yang
memberikan
informasi keluhan terhadap fasilitas dan pelayanan serta memberikan informasi permintaan pelayanan / permintaan fasilitas yang disediakan oleh gedung. 10
Non-Tenant
Individu informasi
atau
perusahaan
permintaan
yang
memberikan
mengadakan
suatu
event/wedding dan atau permintaan sewa. 11
Admin
Individu atau suatu bagian yang melakukan
41
penambahan master data dan update terhadap data yang sudah ada.
4.2.2 Identifikasi Use-Case Persyaratan Bisnis Dalam proses menganalisa persyaratan bisnis dapat mengenali dan mendokumentasikan hanya hal yang paling kritis, kompleks dan penting karena pertimbangan waktu dan biaya. Proses Use-Case persyaratan bisnis diharapkan dapat menangkap interaksi dengan pengguna menggunakan cara yang bebas dari detail teknologi dan implementasi. Untuk mencari use-case persyaratan bisnis adalah dengan menyelidiki para pelaku
dan bagaimana mereka akan
menggunakan sistem. Dalam mendefinisikan persyaratan bisnis, beberapa hal yang perlu diketahui adalah sebagai berikut : 1. Tugas utama dari masing-masing pelaku 2. Informasi apa yang dibutuhkan oleh pelaku sistem 3. Informasi apa saja yang disediakan pelaku untuk sistem 4. Apakah sistem tersebut perlu menginformasikan kepada pelaku tentang segala perubahan atau kejadian yang telah terjadi 5. Apakah ada kebutuhan para pelaku untuk menginformasikan segala perubahan yang terjadi atau kejadian-kejadian yang muncul Diagram konteks merupakan sumber yang bagus untuk menganalisa para pelaku dan mencari use-case potensial. Diagram konteks dapat mengidentifikasi use-case potensial dan mengidentifikasi input dan output utama sistem dan kelompok eksternal. Input utama yang ditujukan untuk kejadian bisnis dengan perusahaan yang menggunakan use-case dan kelompok eksternal yang menyajikan input primer yang melibatkan para pelaku (Whitten, Bentley dan Dittman, 2004). Diagram konteks untuk menentukan use case dari semua proses yang terjadi di dalam divisi Tenant Relation Management dapat dilihat pada Gambar 5.
42
Gambar 5 Diagram Konteks Divisi Tenant Relation Management Pembacaan diagram konteks terkadang tidak terperinci dalam menjelaskan proses sistem karena terlalu banyak dan akan mengacaukan diagram tersebut dan membuatnya sulit untuk di baca. Analisa sistem bertanggung jawab untuk melakukan riset dengan stakeholder yang tepat mengenai tipe output yang mereka terima dan segala karakteristiknya. Tabel 3 di bawah ini merupakan daftar use case yang digunakan untuk mendokumentasikan use case. Daftar ini berisi daftar use case dan pelaku dalam Tenant Relation Management Systems yang teridentifikasi dari diagram konteks.
43
Tabel 3. Daftar Use Case dalam Divisi Tenant Relation Management Nama Use-Case
Deskripsi Use-case
Pelaku dan perannya
Entry Keluhan
Mendeskripsikan pencatatan keluhan 1. Call Center dari tenant yang berhubungan dengan fasilitas gedung, operasional gedung. Misalnya keluhan tenant terhadap
(primer) 2. Control Room (eksternal)
kebersihan, kebisingan dan sebagainya Entry Permintaan
Mendeskripsikan
permintaan- 1. Call Center
permintaan baik itu dari tenant seperti permintaan penambahan daya listrik,
(primer) 2. Marketing event
ijin pekerjaan, dan lain sebagainya serta
dari
bukan
tenant
seperti
permintaan brosur untuk acara event, lokasi kosong untuk perkantoran dan
(eksternal) 3. Marketing Office (eksternal)
lain sebagainya Entry Lembur
Mendeskripsikan
pencatatan 1. Call Center
permintaan lembur dari tenant dan kontraktor yang melakukan pekerjaan di area gedung
(Primer) 2. Control Room (Eksternal)
Prospecting
Mendeskripsikan pencatatan prospek Marketing event
Event
individu
atau
perusahaan
yang
berencana melakukan suatu event Prospecting
Mendeskripsikan
Progress
prospecting event
LOO Event
Mendeskripsikan
(primer)
perkembangan Marketing event (primer) pembuatan
LOO 1. Marketing Event
untuk prospekting event yang sudah setuju dengan syarat-syarat yang telah
(primer)
44
ditentukan
2. Account Receivable (eksternal)
Respon
Mendeskripsikan respons permintaan Marketing Event
Permintaan Event
event kepada tenant ataupun non tenant
(primer)
Prospecting
Mendeskripsikan pencatatan prospek Marketing Leasing
Office
perusahaan yang berencana melakukan
(primer)
penyewaan Prospecting
Mendeskripsikan
Progress
prospecting leasing
LOO Office
Mendeskripsikan
perkembangan Marketing Leasing (primer) pembuatan
LOO 1. Marketing office
untuk prospekting-prospekting office yang sudah setuju dengan syaratsyarat yang telah ditentukan seperti masa kontrak, harga sewa dan service
(primer) 2. Account Receivable (eksternal)
Respon
Mendeskripsikan respons permintaan Marketing Leasing
Permintaan
office kepada tenant
Office Perubahan
(primer)
data Mendeskripsikan pencatatan segala Tenancy
tenant
perubahan informasi dari tenants yang ada, seperti perubahan No NPWP, direksi dan lain sebagainya
Entry Layanan
Mendeskripsikan pencatatan layanan- 1. Tenancy (primer) layanan tambahan yang di minta oleh tenant seperti permintaan layanan TV Cable, pemasangan Lease Line dan
2. Account Receivable
45
lain sebagainya Entry
(eksternal) permintaan 1. Tenancy (primer)
Formulir Mendeskripsikan
Pembelian
pembelian barang atau jasa dari divisi
Barang (FPB)
Tenant Relation Management
Target Divisi
Mendeskripsikan operasional
penetapan
untuk
divisi
(eksternal) target Manager / General Tenant
Relation Management Entry Data
2. Account Payable
Manager
Master Mendeskripsikan penginputan master Admin (Primer) data yang akan digunakan dalam sistem
Update Data
Master Mendeskripsikan
perubahan
dan
Admin (Primer)
pembaharuan terhadap master data
4.3 Desain Proses Divisi Tenant Relation Management 4.3.1 Model Use Case Setelah use-case dan pelaku teridentifikasi, diagram model use-case pun dapat digunakan untuk menggambarkan secara visual lingkup dan batasan sistem. Diagram tersebut dibuat menggunakan Microsoft Visio 2010 dan menunjukan hubungan antar pelaku dan use-case. Selain itu use-case telah dikelompokan menjadi subsistem bisnis. Subsistem tersebut menyatakan area fungsional logika dari proses bisnis. Pembagian kelakuan sistem menjadi subsistem sangat penting untuk memahami arsitektur sistem dan merupakan kunci untuk mendefinisikan strategi pengembangan sistem. Secara garis besar
Sistem Tenant Relation
Management dapat
digambarkan dalam use case diagram, seperti terlihat pada Gambar 6.
46
TRM System Facility Aggrement
Leasing Prospecting
Tenant Update
Prospecting Progress
Tenancy
«Include»
Marketing Leasing
LOO Leasing Tenant List Master
Request Update
«Include»
Renewal
«Include»
Request Handling
«Include»
Event Prospecting
Complaint Handling Prospecting Progress
Call Centre Overtime Requset
Marketing Event
LOO Event Overtime Update Parameter Target Control Room
Complaint Update GM Report Generation
Overtime Approval
Gambar 6 Diagram Use Case Pengembangan DSS Divisi Tenant Relation Management Dalam desain diagram use case Tenant Relation Management tersebut, dapat dijelaskan sebagai berikut : a.
Marketing Leasing
Dalam analisa, marketing Leasing melakukan beberapa aktivitas, yaitu : - Leasing Prospecting Use case dari marketing yang melakukan aktivitas pencatatan informasiinformasi calon tenant ke dalam sistem yang dimana informasi-informasi tersebut akan digunakan seluruhnya oleh use case LOO entry. - Prospecting Progress Use case dari marketing yang melakukan aktivitas pembaharuan status dari calon prospecting yang sesuai dengan kondisi saat ini. Perubahan status ini disertai dengan laporan aktivitas marketing yang telah dilakukan ke calon tenant.
47
- Letter Of Offer Leasing Use case yang dilakukan oleh marketing ketika calon tenant tersebut sudah menyetujui segala sesuatu yang ada di dalam penawaran marketing, seperti harga sewa dan service, masa sewa, dan lain sebagainya. - Renewal Use case yang dilakukan marketing untuk melakukan proses perpanjangan kontrak tenant yang akan habis masa penyewaannya. Proses Use case yang terdapat dalam departemen marketing sangatlah berhubungan satu sama lainnya, sehingga hampir semua use case semua informasi yang dilakukan akan digunakan seluruhnya untuk use case lainnya. b.
Marketing Event - Event Prospecting Use case dari marketing Event yang melakukan aktivitas pencatatan informasi-informasi calon tenant lokasi event ke dalam sistem yang dimana informasi-informasi tersebut akan digunakan seluruhnya oleh use case LOO entry. - Prospecting Progress Use case dari marketing event yang melakukan aktivitas pembaharuan status dari calon prospecting event yang sesuai dengan kondisi saat ini. Perubahan status ini disertai dengan laporan aktivitas marketing yang telah dilakukan ke calon tenant. - Letter Of Offer Event Use case yang dilakukan oleh marketing event ketika calon tenant tersebut sudah menyetujui segala sesuatu yang ada di dalam penawaran marketing event, seperti harga sewa dan service, masa sewa, dan lain sebagainya.
c.
Tenancy Tenancy memiliki beberapa use case, yaitu : - Tenant Update Use case untuk menggambarkan aktivitas tenancy dalam melakukan proses perubahan data informasi tenant. - Facility Agreement
48
Use case yang digunakan untuk melakukan registrasi terhadap perubahan atau penambahan layanan tenant yang disediakan oleh pengelola gedung. Use case ini memiliki hubungan relasi terbatas dengan use case tenant list yang ada di bagian Tenancy. - Tenant List Master Use case untuk melakukan pendaftaran tenant baru yang prosesnya sudah secara otomatis dilakukan pada saat approval LOO dilaksanakan. - Request Update Use case yang melakukan proses update terhadap status permintaan tenant atau non tenant yang telah dilakukan respon oleh departemen terkait. d.
Call Center Dalam proses analisis, call center atau customer service memiliki beberapa use case, yaitu : - Complaint Handling Use case yang digunakan untuk melakukan proses penginputan keluhan dari tenant yang berhubungan dengan fasilitas gedung, kebersihan dan keamanan ke dalam sistem informasi. - Overtime Request Use case yang digunakan untuk melakukan proses penginputan data-data overtime yang di minta oleh tenant. - Request Handling Use case yang ada di customer service yang melakukan proses pencatatan permintaan tenant ataupun bukan tenant yang berhubungan dengan divisi atau departemen lainnya.
e.
General Manager Dalam proses analisa GM hanya melakukan penerimaan laporan untuk semua departemen yang ada di bawah Divisi TRM. Aktivitas tersebut adalah : - Tenant Relation Management Report Generation Use case yang digunakan untuk melakukan proses pembuatan laporan divisi Tenant Relation - Parameter Target
49
Use case yang digunakan untuk menentukan nilai target suatu aktivitas untuk masing-masing departemen. f.
Control Room - Complaint Update Use case yang melakukan proses update terhadap status keluhan yang sudah diinformasikan oleh tenant sehingga pihak call center dapat mengetahui perubahan status untuk masing-masing keluhan. - Overtime Approval Use case yang melakukan proses persetujuan terhadap permintaan lembur yang akan dilakukan. - Overtime Update Use case yang melakukan proses update terhadap permintaan lembur yang secara sistem sudah diaktifkan. Dilihat dari Diagram Use Case Tenant Relation Management pada Gambar 6,
bahwa pekerjaan yang dilakukan setiap aktor memiliki tugas masing-masing. Sehingga dapat dibuatkan Diagram Use Case Pengembangan DSS SubSystems Tenant Relation Management supaya lebih jelas use case untuk setiap aktornya. Gambar Diagram Use Case Pengembangan DSS SubSystems Tenant Relation Management dapat dilihat pada Gambar 7.
50
Tenancy SubSystem
Leasing SubSystem Leasing Prospecting
Facility Aggrement
Prospecting Progress
Tenant Update
Marketing Leasing
LOO Leasing
Tenant List Master
Tenancy
Renewal
Customer Service SubSystem
Event SubSystem
Request Update
Event Prospecting
Complaint Handling
Prospecting Progress
Marketing Event
Request Handling
Call Center
LOO Event Complaint Update
Operational SubSystem
Overtime SubSystem
Parameter Target
Overtime Requset
Overtime Approval GM
Report Generation
Control Room Overtime Update
Gambar 7 Diagram Use Case Pengembangan DSS SubSystems Tenant Relation Management Dari diagram Gambar 7 dapat diketahui SubSystems – SubSystems yang digunakan dalam tahapan pengembangan sistem, SubSystems tersebut adalah sebagai berikut : a.
Leasing SubSystems
b.
Tenancy SubSystems
c.
Event SubSystems
d.
Customer Service SubSystems
51
e.
Operational SubSytem
f.
Overtime SubSystems
Dalam diagram tersebut dapat dilihat juga actor –actor yang terlibat di antara SubSystems – SubSystems yang ada melalui use case yang terdapat pada masingmasing SubSystems.
4.3.2 Model Activity Diagram Setelah didapatkan use case Tenant Relation Management maka desain selanjutnya adalah membuat model Activity Diagram yang menggambarkan berbagai alir aktivitas dalam sistem Tenant Relation Management. a. Call Center Activity Diagram Call Center Activity diagram pada divisi Tenant Relation Management memiliki aktivitas-aktivitas seperti terlihat pada Lampiran 1 dan Lampiran 2 untuk : 1.
Use Case Complaint Handling Dimulai dari mendapatkan complaint information dari tenant atau non tenant baik melalui telepon, email atau website, proses open new complaint form entry dan menginput informasi keluhan, lalu melakukan proses pemeriksaan data tenant. Apakah termasuk tenant? Jika tidak maka melakukan proses entry non tenant information dan jika ya maka melakukan search tenant list yang sudah ada dan pilih tenant, kemudian melakukan proses pilih tipe complaint setelah itu proses entry complaint detail, proses selesai.
2.
Use Case Complaint Update Dimulai ketika Control Room akan melakukan perubahan status terhadap complaint yang sudah diselesaikan. Pihak control room atau departemen terkait akan membuka tampilan daftar semua complaint, melakukan pencarian terhadap complaint yang sudah selesai, kemudian melakukan update untuk status terakhir (Done, Pending, Cancel).
3.
Use case Request Handling Dimulai dari permintaan tenant ataupun non tenant terhadap pengelola gedung. Dalam hal ini call center akan membuka tampilan input Request
52
Handling, menentukan apakah pihak yang meminta adalah tenant atau non tenant, jika non tenant maka pihak call center akan mengisikan data-data informasi berdasarkan informasi yang di dapat. Jika tenant maka call center hanya memilih data tenant tersebut. Kemudian call center akan memilih tipe atau jenis permintaan yang diminta yang dilanjutkan dengan pengisian permintaan lebih detail. 4.
Use Case Request Update Dimulai ketika departmen yang bersangkutan akan melakukan perubahan status terhadap complaint yang sudah diselesaikan. Pihak control room atau departemen terkait akan membuka tampilan daftar semua permintaan, melakukan pencarian terhadap permintaan yang sudah diselesaikan, kemudian melakukan update untuk status terakhir (Done, Pending, Cancel).
b. Marketing Leasing Activity Diagram Marketing Leasing Activity diagram pada divisi Tenant Relation Management memiliki aktivitas-aktivitas seperti terlihat pada Lampiran 3 dan Lampiran 4 untuk : 1.
Use Case Leasing Prospecting Dimulai dengan adanya kebutuhan suatu perusahaan untuk melakukan penyewaan baik itu secara email, telpon ataupun kunjungan. Informasi tersebut akan dimasukan oleh call center dengan membuka tampilan input prospecting dan melakukan pencarian di sistem terhadap data yang sudah di terima dari calon tenant. Jika data yang diberikan sudah terdapat di dalam sistem maka call center dapat melakukan update informasi tehadap calon tenant tersebut dan jika informasi calon tenant tersebut tidak ada di dalam sistem, maka call center melakukan proses penginputan untuk data calon tenant baru.
2.
Use Case Prospecting Progress Proses ini bermula ketika terjadi interaksi antara marketing dan calon tenant. Marketing akan melakukan pencarian data calon tenant tersebut di dalam sistem kemudian marketing akan membuka tampilan untuk
53
prospecting progress dan memasukan informasi-informasi berdasarkan hasil interaksi dengan calon tenant ke dalam sistem beserta status dari masing-masing prospecting, status tesebut adalah : a. Inquiry, merupakan status awal dari calon tenant dimana ketertarikan calon tenant terhadap lokasi yang akan di sewa. b. On Going, merupakan status dari calon tenant dimana calon tenant tersebut sudah melakukan beberapa interaksi dengan marketing dan sudah melakukan kunjungan terhadap lokasi yang diminati. c. Reserved, merupakan status dari calon tenant dimana calon tenant sudah menyetujui harga, kondisi dan lain sebagainya. d. Lease Agreement, merupakan status dari calon tenant dimana calon tenant dalam proses pembuatan kontrak sewa menyewa. 3.
Use Case LOO Leasing Proses ini merupakan proses pembuatan kontrak dari calon tenant yang dalam status reserved. Marketing akan melakukan pencarian terhadap data-data calon tenant dengan status reserved. Setelah itu, marketing akan melakukan input kontrak sewa , pemilihan lokasi yang diinginkan, periode LCD dan LED, nilai rental dan service serta besaran security deposit.
4.
Use Case Renewal Merupakan proses perpanjangan kontrak, yang bermula dari penyeleksian dari daftar tenant yang akan habis masa kontraknya dalam 3 bulan ke depan. Setelah itu marketing akan memasukan periode sewa baru beserta informasi besaran rate sewa dan rental serta security deposit baru dan kemudian marketing melakukan proses persetujuan atas perpanjangan kontrak tersebut.
c. Marketing Event Activity Diagram Marketing
Event Activity diagram pada divisi Tenant Relation
Management memiliki aktivitas-aktivitas seperti terlihat pada Lampiran 5 untuk : 1.
Use Case Event Prospecting Dimulai dengan adanya kebutuhan suatu perusahaan atau individu untuk melakukan suatu acara event ataupun wedding baik itu secara email, telpon
54
ataupun kunjungan. Informasi tersebut akan dimasukan oleh call center dengan membuka tampilan input prospecting event dan melakukan pencarian di sistem terhadap data-data yang sudah di terima dari calon tenant. Jika data yang diberikan sudah terdapat di dalam sistem maka call center dapat melakukan update informasi tehadap calon tenant tersebut jika terdapat perbedaan informasi dengan yang ada di sistem dan jika informasi calon tenant tersebut tidak ada di dalam sistem maka call center melakukan proses penginputan untuk data calon tenant baru. 2.
Use Case Prospecting Progress Event Proses ini bermula ketika terjadi interaksi antara marketing event dengan calon tenant event. Marketing akan melakukan pencarian data calon tenant event tersebut di dalam sistem kemudian marketing akan membuka tampilan untuk prospecting progress event dan memasukan informasiinformasi berdasarkan hasil interaksi dengan calon tenant ke dalam sistem beserta status dari masing-masing prospecting event, status tesebut adalah: a.
Inquiry, merupakan status awal dari calon tenant event dimana ketertarikan calon tenant terhadap lokasi yang akan di sewa.
b.
On Going, merupakan status dari calon tenant dimana calon tenant tersebut sudah melakukan beberapa interaksi dengan marketing dan sudah melakukan kunjungan terhadap lokasi yang diminati.
c.
Reserved, merupakan status dari calon tenant dimana calon tenant sudah menyetujui harga, kondisi dan lain sebagainya.
d.
Lease Agreement, merupakan status dari calon tenant dimana calon tenant dalam proses pembuatan kontrak sewa menyewa.
3.
Use Case LOO Event Proses ini merupakan proses pembuatan kontrak dari calon tenant event yang dalam status reserved. Marketing akan melakukan pencarian terhadap data calon tenant dengan status reserved. Setelah itu, marketing akan melakukan input kontrak event, pemilihan lokasi yang diinginkan, periode LCD dan LED , nilai sewa serta besaran security deposit.
55
d. Tenancy Activity Diagram Tenancy Activity diagram pada divisi Tenant Relation Management memiliki aktivitas-aktivitas seperti terlihat pada Lampiran 6 adalah : 1.
Use Case Facility agreement Dimulai ketika tenant mengajukan untuk penambahan fasilitas yang disediakan oleh gedung. Tenancy akan melakukan pencarian terhadap tenant yang akan melakukan penambahan fasilitas, kemudian tenancy akan melakukan pemilihan tipe layanan berdasarkan kebutuhan dari tenant, memasukan periode layanan serta
besaran sewa fasilitas. Setelah itu
tenancy akan melakukan persetujuan terhadap fasilitas tersebut. 2.
Use Case Tenant Update Bermula ketika ada perubahan dari data tenant yang diinformasikan ke pihak tenancy. Kemudian pihak tenancy akan melakukan pencarian terhadap tenant tersebut,kemudian tenancy akan melakukan update terhadap data-data tenant berdasarkan informasi yang di dapat.
3.
Use Case Tenant List Master Bermula ketika tenancy akan menampilkan semua informasi-informasi tenant. Tenancy akan memilih periode kontrak, pemilihan tenant dan menampilan semua informasi mengenai tenant tersebut.
e. Overtime Activity Diagram Overtime Activity diagram pada divisi Tenant Relation Management memiliki aktivitas-aktivitas seperti terlihat pada Lampiran 7 adalah : 1.
Use Case Event Overtime Request Bermula ketika tenant melakukan permintaan overtime baik itu dengan menggunakan email ataupun mengisi form yang sudah ada. Call center akan membuka tampilan input overtime kemudian memasukan tanggal dan jam awal overtime dan akhir overtime. Setelah itu call center akan melakukan pemilihan lokasi atas tenant tersebut, pemilihan tipe overtime.
2.
Use Case Overtime Approval Use case ini dimulai ketika pihak control room melakukan setup dengan BAS sistem atas permintaan overtime yang ada, setelah melakukan hal
56
tersebut pihak control room akan melakukan proses persetujuan atas overtime yang masuk.
4.3.3 Model Class Diagram Berdasarkan dari diagram-diagram aktivitas maka dapat dilihat kebutuhan atribut apa saja yang dikembangkan pada desain Class Diagram divisi Tenant Relation Management dan bagaimana hubungan di antara class. Class Diagram yang dilakukan pada Divisi Tenant Relation Management dapat dilihat pada gambar-gambar diagram di bawah ini. a. Complaint Handling Class Diagram Complaint Handling Class Diagram pada divisi Tenant Relation Management memiliki class-class seperti terlihat pada Gambar 8.
Gambar 8 Complaint Handling Class Diagram Penjelasan dari Gambar 8 bahwa tenant atau non tenant dapat mengajukan complaint ke Call Center dengan maksud satu tenant atau non tenant dapat mengajukan satu atau lebih complaint yang diajukan kepada pengelola gedung. Pada complaint handling pihak call center dapat melakukan update terhadap status complaint untuk satu atau beberapa complaint dalam sekali proses.
b. Request Handling Class Diagram Request
Handling
Class Diagram pada divisi Tenant
Management memiliki class-class seperti terlihat pada Gambar 9.
Relation
57
Gambar 9 Request Handling Class Diagram Penjelasan dari Gambar 9 memungkinkan tenant atau Non tenant menyampaikan permohonan permintaan dimana satu tenant atau Non tenant dapat menyampaikan lebih dari satu permintaan. Pihak atau departemen yang menangani keluhan tersebut dapat melakukan update terhadap permintaan tersebut secara bersamaan dimana permintaan tersebut lebih dari satu permintaan.
c. Leasing Class Diagram Leasing Class Diagram pada divisi Tenant Relation Management memiliki class-class seperti terlihat pada Gambar 10.
58
Gambar 10 Leasing Class Diagram Gambar 10 dapat dijelaskan sebagai berikut : •
Add Activity, merupakan kondisi satu propsecting dapat memiliki lebih dari satu aktivitas yang dilakukan.
•
Reserved Status, merupakan kondisi dimana satu prospecting yang sudah dalam kondisi status reserved dapat dibuatkan satu LOO atas prospecting tersebut.
•
LOO Approved, merupakan kondisi satu LOO yang sudah lengkap yang akan disetujui.
•
Schedule Generate, merupakan kondisi pembuatan jadwal tagihan sewa, service dan deposit dimana satu buah LOO yang sudah disetujui dapat membentuk lebih dari satu jadwal penagihan yang ditentukan juga oleh periode sewa untuk tenant.
•
Schedule Processed, merupakan kondisi pembuatan invoice dari jadwal yang sudah terbentuk. Jumlah invoice yang terbentuk untuk periode tertentu, tergantung dari jumlah schedule yang akan dibuatkan invoicenya.
59
•
Invoice Posted, merupakan kondisi posting satu atau beberapa invoice ke dalam Journal yang akan terbentuk jurnal yang sesuai dengan jumlah invoice yang di posting.
•
Payment, merupakan kondisi dimana pembayaran satu invoice dapat dilakukan dengan satu atau lebih pembayaran dengan syarat bahwa invoice tersebut sudah dilakukan posting.
•
Posted, merupakan kondisi dimana satu pembayaran yang dilakukan akan di posting ke journal sebanyak satu transaksi journal
d. Event Class Diagram Event Class Diagram pada divisi Tenant Relation Management memiliki class-class seperti terlihat pada Gambar 11.
Gambar 11 Event Class Diagram Gambar 11 dapat dijelaskan sebagai berikut : •
Add Activity, merupakan kondisi satu propsecting event dapat memiliki lebih dari satu aktivitas yang dilakukan.
60
•
Reserved Status, merupakan kondisi dimana satu prospecting event yang sudah dalam kondisi status reserved dapat dibuatkan satu LOO Event atas prospecting event tersebut.
•
LOO Approved, merupakan kondisi satu LOO Event yang sudah lengkap yang akan disetujui.
•
Schedule Generate, merupakan kondisi pembuatan jadwal tagihan sewa Event dan deposit Event yang dimana satu buah LOO Event yang sudah disetujui dapat membentuk lebih dari satu jadwal penagihan yang ditentukan juga oleh periode sewa event untuk tenant.
•
Schedule Processed, merupakan kondisi pembuatan invoice Event dari jadwal yang sudah terbentuk. Jumlah invoice Event yang terbentuk untuk periode tertentu tergantung dari jumlah schedule yang akan dibuatkan invoicenya.
•
Invoice Posted, merupakan kondisi posting satu atau beberapa invoice Event ke dalam Journal yang akan terbentuk jurnal yang sesuai dengan jumlah invoice Event yang di posting.
•
Payment, merupakan kondisi dimana pembayaran satu invoice event dapat dilakukan dengan satu atau lebih pembayaran dengan syarat bahwa invoice Event tersebut sudah dilakukan posting.
•
Posted, merupakan kondisi dimana satu pembayaran yang dilakukan akan di posting ke journal sebanyak satu transaksi journal.
e. Overtime Class Diagram Overtime Class Diagram pada divisi Tenant Relation Management memiliki class-class seperti terlihat pada Gambar 12.
61
Gambar 12 Overtime Class Diagram Gambar 12 dapat dijelaskan sebagai berikut : •
Overtime Register, merupakan kondisi dimana satu tenant dapat melakukan lebih dari satu permintaan overtime.
•
Overtime Status, merupakan kondisi persetujuan terhadap overtime dimana pihak terkait dapat melakukan persetujuan untuk lebih dari satu permintaan overtime dalam waktu yang bersamaan.
•
Schedule Generate, merupakan kondisi pembuatan jadwal tagihan overtime yang berawal dari class diagram Overtime approval untuk permintaan overtime yang telah disetujui dan membentuk jadwal sejumlah permintaan overtime yang sudah disetujui.
•
Schedule Processed, merupakan kondisi pembuatan invoice dari jadwal yang sudah terbentuk. Jumlah invoice yang terbentuk untuk periode tertentu tergantung dari jumlah schedule yang akan dibuatkan invoicenya
•
Invoice Posted, merupakan kondisi posting satu atau beberapa invoice overtime ke dalam Journal yang sesuai dengan jumlah invoice yang di posting.
•
Payment, merupakan kondisi dimana pembayaran satu invoice dapat dilakukan dengan satu atau lebih pembayaran dengan syarat bahwa invoice tersebut sudah dilakukan posting.
62
•
Posted, merupakan kondisi dimana satu pembayaran yang dilakukan akan di posting ke journal sebanyak satu transaksi journal.
f. Tenant Relation Management Class Diagram Tenant Relation Management Class Diagram memiliki class-class seperti terlihat pada Gambar 13. Activity Reserved LOO Event Class
1
-LOO Approval
1
-Prospecting_event_id -LOO_event_no -LOO_event_date -Period_from -Period_to -Lot_event -rental_event__rate -Rental_event_deposit -Rental_event_currency -Rental_deposit_currency -charge_cycle -interval_charge +Search_prospecting_event() +Get_loo_Event_no() +Get_loo_event_date() +Calc_rental_event() +Calc_rental_event_deposit() +Edit() +Save()
1 -Reserved Status
1
1
Progressing Event Detail -activity_event_id -Activity_event_date -Activity_event_description
-Prospecting_event_id -Tenant_id -Approval_date +get_tenant_id() +Update_status_prospecting_event()
1..* 1
1..*
-Schedule Generate
1..* -Generated Invoice 1..*
+get_invoice_no() +get_date() +calc_total() +posting_to_gl()
1
1..*
Overtime
-Schedule_id -Tenant_no -Bill_type -Bill_date -Period_from -Period_to -bill_desc -bill_curr -Bill_amount -Bill_ppn -Bill_pph -Bill_sd -Bill_status +get_schedule_id() +Calc_total_bill() +Cacl_ppn_bill() +Calc_pph_bill() +schedule_process()
-Overtime_id -Tenant_id -Overtime_date_from -Overtime_time_from -Overtime_date_to -Overtime_time_to -Overtime_type
1..* -Schedule Generate
1
Purchase Requisition Detail
Purchase order Detail
-Request_id -Item_code -Item_desc -Measurement -qty_requset -qty_approved -budget_code +Search_budget_code() +Search_item_code()
-po_id -Item_code -Item_desc -Measurement -qty_approved -item_prices -budget_code
1
1..*
1
-Reserved Status
-Overtime Register
-Tenant_ID -Tenant_Name -PIC -Phone_no -Unit_code
1..*
1 1
-Complaint Register 1..*
Non Tenant -Non_tenant_id -Name -Company -Phone_no -Cellular_no -Email
-Overtime Status
-Prospecting_id -Prospecting_type -Prospecting_date -Prospecting_company -Business_line -Prospecting_phone -Prospecting_email -Prospecting_search_area -Prospecting_lcd -Prospecting_status +Search_tenant() +Get_date() +Get_time() +View_prospecting_status() +View_business_line_category() +Edit() +Save()
1
-Overtime_id -Overtime_status -Overtime_remarks +Get_date() +Get_time() +Update() +Schedule_generation()
-Prospecting_id -Tenant_id -Approval_date +get_tenant_id() +Update_status_prospecting()
-Add Activity 1..*
Complaint Handling
Complaint Update
-Complaint_id -Complaint Status -Compalint_date -Complaint_time -Complaint_type 1..* 1..* -Complaint_register -Complaint_dept -Complaint_detail +Search_tenant() +Get_date() +Get_time() +Save() +Edit() +Get_complaint_id() +Status Update()
-Complaint_id -Status -Remaks +Get_date() +Get_time() +Update()
1..* -Request Register 1..*
-Request_id -Request_date -Request_time -Request_type -Request_register -Request_dept_to -Request_detail +Search_tenant_no_tenant() +Get_date() +Get_tim() +Save() +Edit() +Get_request_id()
Request Update -Request Status 1..*
1..*
-Request_id -Status -Remaks +Get_date() +Get_time() +Update()
Prospecting Progress -Activity_id -Prospecting_id -Lot_selection +Get_activity_id() +Get_date() +View_available_lot() +Add() +Edit() +Save()
1
+Get_po_bo() +Get_date() +posting_to_gl()
Request handling 1
-Request Register
1..*
1
-PO_no -PO_date -request_id -Supplier -Supplier_tax_scheme
+calc_total_po() +Calc_ppn() +calc_pph()
Overtime Approal & Update
Prospecting
1
1
+search_tenant() +Get_date_from() +Get_date_to() +Get_time_from() +Get_time_to() +Get_overtime_id()
1..*
1
-LOO Approval
Tenant 1..*
1..*
1..*
-Approved 1
1
+Get_activity_event_id() +Get_date() +View_available_lot_event() +Add() +Edit() +Save()
LOO Approval
1
1
PR Approval -Request_id -Request_approval +Get_date() +Update_ purchase_Requisition()
+Get_request_id() +Get_date()
1..*
Billing Schedule
-Shedule Generate
LOO Class -Prospecting_id -LOO_no -LOO_date -Period_from -Period_to -Lot -rental_rate -Service_rate -Rental_deposit -Service_deposit -Rental_currency -Service_currency -Rental_deposit_currency -Service_deposit_currency -charge_cycle -interval_charge +Search_prospecting() +Get_loo_no() +Get_loo_date() +Calc_rental() +calc_service() +Calc_rental_deposit() +Calc_service_deposit() +Edit() +Save()
-PR Approval
-Complaint Register
Invoice
Activity Reserved
+Add() +Edit() +Save()
Prospecting Event Progress
-Add Activity
Purchase Order
Purchase Requisition -Request_id -Request_date -Request_user -Request_divisi -Requset_desc -status
1
-Activity_event_id -Prospecting_event_id -Lot_event_selection
LOO Event Approval
-Invoice_no -Schedule_id -invoice_date -due_date -Tenant_no -bill_type -base_amount -PPN_amount -pph_amount -status -Posting
Prospecting Event -Prospecting_event_id -Prospecting_event_type -Prospecting_event_date -Prospecting_event_name -Prospecting_event_phone -Prospecting_event_email -Prospecting_event_type -Prospecting_lcd -Prospecting_status +Search_tenant_event() +Get_date() +Get_time() +View_prospecting_event_status() +Edit() +Save()
1
Progressing Detail -activity_id -Activity_date -Activitt_description
1..*
+Add() +Edit() +Save()
Gambar 13 Tenant Relation Management Class Diagram
4.3.4 Model Sequence Diagram Model sequence diagram pada divisi Tenant Relation Management akan menggambarkan skenario atau serangkaian interaksi yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu yang dibutuhkan oleh aktor.
63
a.
Call Center Sequence Diagram Call Center memiliki 4 aktivitas pekerjaan yang dapat dilihat seperti di bawah
ini : 1. Complaint Handling Sequence Diagram Complaint Handling Sequence Diagram pada Call Center digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 8. 2. Complaint Update Sequence Diagram Complaint Update Sequence Diagram pada Call Center digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 9. 3. Request Handling Sequence Diagram Request Handling Sequence Diagram pada Call Center digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 10. 4. Request Update Sequence Diagram Request Update Sequence Diagram pada Call Center digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 11.
b. Marketing Leasing Sequence Diagram Marketing Leasing memiliki 4 aktivitas pekerjaan yang dapat dilihat seperti di bawah ini : 1. Leasing Prospecting Sequence Diagram Leasing Prospecting Sequence Diagram pada Marketing Leasing digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 12. 2. Prospecting Progress Sequence Diagram Prospecting Progress Sequence Diagram pada Marketing Leasing digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 13. 3. LOO Leasing Sequence Diagram LOO Leasing Sequence Diagram pada Marketing Leasing digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 14. 4. Renewal Sequence Diagram Renewal
Progress
Sequence
Diagram
pada
Marketing
Leasing
digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 15.
64
c.
Marketing Event Sequence Diagram Marketing Event memiliki 3 aktivitas pekerjaan yang dapat dilihat seperti di bawah ini : 1. Event Prospecting Sequence Diagram Event Prospecting Sequence Diagram pada Marketing Event digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 16. 2. Event Prospecting Progress Sequence Diagram Event Prospecting Progress Sequence Diagram pada Marketing Event digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 17. 3. LOO Event Sequence Diagram LOO Event Sequence Diagram pada Marketing Event digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 18.
d. Tenancy Sequence Diagram Tenancy memiliki 2 aktivitas pekerjaan yang dapat dilihat seperti di bawah ini : 1. Facility Agreement Sequence Diagram Facility Agreement Sequence Diagram pada Tenancy digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 19. 2. Tenant Update & Tenant List Sequence Diagram Tenant Update & Tenant List Sequence Diagram pada Tenancy digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 20.
e.
Overtime Sequence Diagram Overtime memiliki 2 aktivitas pekerjaan yang dapat dilihat seperti di bawah ini : 1. Overtime Request Sequence Diagram Overtime Request Sequence Diagram pada Overtime digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 21. 2. Overtime Update & Approval Sequence Diagram Overtime Update Sequence Diagram pada Overtime digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 22.
65
4.4 Implementasi Sistem Tenant Relation Management Berdasarkan analisis dan desain sistem
Tenant Relation Management
yang sudah dilakukan, maka dilakukan pengembangan sistem pada fase implementasi dengan menggunakan perangkat lunak Power Builder 11.5 dan database engine SQL Anywhere 8. 4.4.1 Menu Program Hasil dari analisis dan desain sistem berdasarkan parameter KPI yang ada pada divisi Tenant Relation Management setelah diimplementasikan dalam bentuk aplikasi maka menghasilkan tampilan-tampilan seperti gambar-gambar di bawah ini. a. Struktur Menu Program struktur menu program yang ada terdiri atas 2 tampilan, dimana transaksitransaksi yang terjadi pada struktur menu aplikasi sistem informasi Tenant Relation Management akan mempengaruhi aplikasi report KPI pada TRM. Tampilan Aplikasi struktur menu program yang ada adalah : 1. Aplikasi Sistem Informasi Tenant Relation Management Struktur menu program ini merupakan struktur hirarki sistem Tenant Relation Management dari aktivitas-aktivitas yang dilakukan oleh 3 departemen di bawahnya yaitu : departemen Marketing, Customer Service dan Tenancy dalam tampilan program dan menu-menu apa saja yang ada. Struktur menu program aplikasi sistem Tenant Relation Management bisa terlihat seperti Gambar 14.
Gambar 14 Struktur Menu Aplikasi TRM
66
Gambar 14 ini memperlihatkan struktur menu aplikasi dari sistem informasi pada divisi TRM untuk tampilan transaksi apa saja yang digunakan dan disediakan. 2. Aplikasi Report Key Performance Indicator pada Tenant Relation Management Struktur
menu
program
ini merupakan
struktur
aplikasi untuk
memperlihatkan hasil report dari transaksi-transaksi yang dilakukan pada aplikasi sistem informasi pada divisi TRM yang dibandingkan dengan parameter KPI yang sudah ada. Tampilan program yang ada akan digunakan oleh manager ataupun manajemen perusahaan sebagai bahan dalam pengambilan keputusan. Struktur menu aplikasi Report Key Performance Indicator pada Tenant Relation Management terlihat seperti Gambar 15.
Gambar 15 Struktur Menu Aplikasi Report Key Performance Indicator Gambar 15 memperlihatkan tampilan struktur menu aplikasi Report Key Performance Indicator yang terjadi pada divisi TRM berdasarkan transaksitransaksi yang terjadi berdasarkan departemen-departemen yang terkait. Tampilan ini menampilkan sesuai kelompok dari parameter KPI di bagian Call Center, Marketing dan Expenses & Income. b. Menu Login Program dan Inputan Memperlihatkan dari tampilan login dan contoh tampilan input dari transaksi yang terjadi dari 3 departemen. 1. Menu Login Program Tampilan menu login program untuk aplikasi sistem informasi pada divisi Tenant Relation Management dapat dilihat pada Gambar 16.
67
Gambar 16 Tampilan Login Program pada Divisi TRM
2. Input Transaksi Departemen Marketing Proses input transaksi prospecting tenant pada departemen Marketing dapat dilihat pada tampilan Gambar 17.
Gambar 17 Tampilan Input Proses Prospecting Tenant di Departemen Marketing
68
Gambar 17 menampilkan input proses prospecting tenant di departemen Marketing, dimana untuk prospecting ID dan date secara otomatis sudah terisi ketika akan menambahkan calon tenant. Aktivitas yang harus dilakukan oleh marketing adalah mengisi nama calon tenant, kontak person yang bisa bertanggungjawab dari perusahaan tenant, no telpon dan handphone, email tenant, untuk kategori apakah leasing atau event yang mau dipilih sesuai permintaan dari tenant, alamat calon tenant sebelum menyewa gedung, status dari tenant yaitu inquiry atau reserved, target rencana akan masuk gedung dan terakhir adalah mengisi luas area yang diinginkan tenant. Setelah proses input ini selesai proses selanjutnya adalah prospecting activity yang merupakan proses tindaklanjut dari marketing terhadap calon tenant yang masih inquiry, setelah itu proses selanjutnya adalah input contract atau agreement dimana proses ini pembuatan kontrak yang disetujui antara tenant dan pengelola gedung sampai penandatanganan surat kontrak. Maka tugas dari marketing selesai.
3. Input Transaksi Departemen Customer Service Proses input transaksi Complaint pada departemen Customer Service dapat dilihat pada tampilan Gambar 18.
Gambar 18 Tampilan Input Proses Complaint di Departemen Customer Service Gambar 18 menampilkan Input Proses Complaint di Departemen Customer Service, dimana untuk tampilan ID, Date dan Time secara otomatis sudah ke isi sewaktu mau menambahkan complaint yang masuk, bagian Customer Service melakukan pengisian untuk kolom nama tenant dengan cara mencari data nama perusahaan tenant yang sudah ada, nama orang yang mengajukan complaint
69
dari perusahaan tenant, nama orang yang menerima dan menginput complaint ke sistem, pilih kategori yang akan di complaint, masukan departemen yang terkait dengan complaint, pilih status complaint yang masuk dan yang terakhir adalah mendeskripsikan complaint yang diminta oleh tenant. Setelah data complaint masuk, maka bagian control room akan memberitahukan ke bagian departemen terkait agar cepat merespon complaint tersebut. Setelah selesai di respons oleh departemen terkait baru dibuatkan laporan sudah dilakukan, untuk memastikan kerjaan complaint telah dilaksanakan maka bagian customer service mengecek kepada tenant yang complaint, lalu mengisi form laporan jika complaint sudah dilakukan, maka proses complaint selesai. Proses input transaksi Overtime pada departemen Customer Service dapat dilihat pada tampilan Gambar 19.
Gambar 19 Tampilan Input Proses Overtime di Departemen Customer Service Gambar 19 menampilkan Input Proses Overtime di Departemen Customer Service, dimana untuk tampilan Overtime No. Sudah terisi secara otomatis oleh sistem, bagian Customer Service melakukan pengisian untuk kolom nama tenant dan lokasi dengan cara mencari data nama perusahaan tenant yang sudah ada, isi request date overtime, nama orang yang mengajukan overtime dari perusahaan tenant, tipe jenis fasilitas yang akan di overtime charges, date dan time mulai overtime dan masukan date dan time terakhir overtime. 4. Input Transaksi Departemen Tenancy Proses input transaksi data tenant pada departemen Tenant Relation dapat dilihat pada tampilan Gambar 20.
70
Gambar 20 Tampilan Input Proses Data Tenant di Departemen Tenancy Gambar 20 menampilkan Input dan Edit Proses data tenant di Departemen Tenancy. Setelah data di retrieve lalu pilih data tenant yang mau di edit maka akan tampil windows seperti gambar di atas. Bagian Tenancy tinggal mengedit data yang mau di ganti dan bisa mengisi bagian kolom yang masih kosong untuk melengkapi data tenant. Proses input transaksi Contract Facility pada departemen Tenant Relation dapat dilihat pada tampilan Gambar 21.
71
Gambar 21 Tampilan Input Proses Contract Facility di Departemen Tenancy Gambar 21 menampilkan Input dan Edit Proses Contract Facility di Departemen Tenancy. Setelah melakukan new contract untuk facility tambahan akan ada perubahan data tenant yang pertama pilih lot/unit no yang akan mengisi area secara otomatis, pilih tipe tambahan fasilitas yang diinginkan, cara pembayaran dan besaran harga sewa dalam kurs mata uang apa, pajak 10 % untuk pembayaran, masukan periode mulai sewa dan berakhir sewa, pilih cara pembayaran per bulan dengan interval waktu 3 bulan. 5. Input Target Parameter oleh Manager Proses input target parameter oleh Manager dapat dilihat pada tampilan Gambar 22.
Gambar 22 Tampilan Input Proses Target KPI Gambar 22 menampilkan Input Proses target KPI yang dilakukan oleh Manager divisi TRM. Jika parameter KPI yang ada di edit maka akan mempengaruhi report KPI yang merupakan hasil transaksi yang terjadi di divisi
72
TRM karena parameter akan berubah sesuai editan baru, sehingga target parameter KPI menjadi baru.
4.4.2 Output / Report Program Menampilkan hasil dari transaksi-transaksi yang terjadi dari sistem informasi divisi TRM yang telah dilakukan oleh 3 departemen terhadap tenant. Hasil report ini akan dijadikan perbandingan dengan target parameter yang sudah ada. a. Output / Report Sistem Informasi Divisi TRM Report dari sistem informasi divisi TRM yang diambil hanya bagian hasil report dari transaksi-transaksi yang berhubungan dengan target KPI yang akan di capai. 1. Output Marketing a). Proses Prospecting Tenant Report proses Prospecting Tenant pada departemen Marketing dapat dilihat pada Gambar 23.
Gambar 23 Tampilan Report Proses Prospecting Tenant Gambar 23 menampilkan list prospecting tenant yang harus di follow up oleh bagian departemen marketing, supaya menjadi tenant di divisi TRM.
73
b). Listing Renewal Report proses renewal pada departemen Marketing dapat dilihat pada Gambar 24.
Gambar 24 Tampilan Report Proses Renewal Gambar 24 menampilkan list tenant yang mau habis masa kontraknya, maka tugas dari bagian departemen marketing untuk menawarkan dan negosiasi terhadap tenant tersebut supaya tetap menjadi tenant di divisi TRM, dengan cara memperpanjang kontrak sewa. 2. Output Customer Service a). Proses Complaint Report proses Complaint pada departemen Customer Service dapat dilihat pada Gambar 25.
74
Gambar 25 Tampilan Report Proses Complaint Gambar 25 menampilkan list complaint yang ada di bagian departemen Customer Service dan bagaimana status complaint tersebut. b). Proses Overtime Report proses Overtime pada departemen Customer Service dapat dilihat pada Gambar 26.
Gambar 26 Tampilan Report Proses Overtime Gambar 26 menampilkan list Overtime yang ada di bagian departemen Customer Service dan berapa income dari transaksi tersebut sebagai masukan rental service.
75
3. Output Tenancy a). Tenant List Report proses Tenant List pada departemen Tenancy dapat dilihat pada Gambar 27.
Gambar 27 Tampilan Report Proses Tenant List Gambar 27 menampilkan Tenant List yang ada di bagian departemen Tenancy, data tenant sudah yang terbaru dan lebih lengkap. b). Facility Agreement Report proses Facility Agreement pada departemen Tenancy dapat dilihat pada Gambar 28.
76
Gambar 28 Tampilan Report Proses Facility Agreement Gambar 28 menampilkan income yang dihasilkan dari proses Facility Agreement yang ada di bagian departemen Tenancy dan menggambarkan fasilitas tambahan apa saja yang diminta oleh tenant.
b. Output / Report Key Performance Indicator Report dari hasil transaksi sistem informasi divisi TRM yang berhubungan dengan target KPI yang akan di capai. Laporan report KPI ini yang merupakan pengembangan DSS yang berbasis KPI, karena di report ini terjadinya perbandingan report transaksi kenyataan dengan target parameter KPI yang merupakan tujuan dari manajemen. 1. Report Customer Service / Call Center Pada departemen Call Center ini memiliki 4 laporan report yang dibandingkan dengan parameter target KPI, yaitu : a). Complaint Status Report KPI proses Complaint Status pada departemen Call Center dapat dilihat pada Gambar 29.
77
Gambar 29 Tampilan Report KPI Proses Complaint Status Gambar 29 menggambarkan persentase yang dihasilkan dari proses Complaint Status yang ada pada departemen Call Center. Data persentase yang di dapat menghasilkan simpulan bahwa kondisi Complaint status tidak mencapai target dari manajemen diperkuat dengan tampilan list complaint status, yang bisa ditampilkan dengan mengklik tombol tulisan detail. Manager dapat melihat target KPI tidak tercapai dengan melihat tulisan saja, jika warna merah tidak tercapai dan jika warna hijau maka target dari KPI tercapai. Report target Complaint status ini juga diperkuat dengan kondisi yang menyatakan jika target tidak tercapai ataupun tercapai. Report KPI complaint status ini menggambarkan berapa jumlah complaint yang masuk, yang sudah dikerjakan dan yang belum dengan memperlihatkan
persentase
dari
masing-masing
transaksi
tersebut,
lalu
dibandingkan dengan target parameter KPI. b). Complaint Response Time Report KPI proses Complaint Response Time pada departemen Call Center dapat dilihat pada Gambar 30.
78
Gambar 30 Tampilan Report KPI Proses Complaint Response Time Gambar 30 memperlihatkan kalkulasi yang dihasilkan dari proses Complaint Response Time yang ada pada departemen Call Center. Berdasarkan Complaint yang masuk dari tenant sebanyak 24 kasus, dari hasil simulasi ada 19 complaint yang kondisinya sudah dilakukan response. Data 19 complaint ini dapatnya bisa dilihat pada data detail yang tersedia dari hasil transaksi sistem informasi TRM pada departemen Call Center. Hasil rata-rata waktu response time yang di dapat dari transaksi dibandingkan dengan target rata-rata parameter KPI untuk Complaint response time, jika memenuhi target parameter maka kondisi target tercapai dengan melihat tulisan hijau di report KPI complaint response time. Report ini juga diperkuat dengan gambar grafik yang memperjelaskan kondisi jumlah complaint yang belum di response, jumlah complaint yang di response over dari 15 menit dan yang before dari 15 menit dengan memperlihatkan persentase dari total complaint. c). Inquiry Report KPI proses Inquiry pada departemen Call Center dapat dilihat pada Gambar 31.
79
Gambar 31 Tampilan Report KPI Proses Inquiry Gambar 31 memperlihatkan persentase yang dihasilkan dari proses Inquiry di bagian departemen Call Center. Berdasarkan Inquiry yang masuk dari tenant sebanyak 17 inquiry, dari hasil simulasi ada 15 inquiry yang kondisinya sudah dikerjakan LOO dan 2 inquiry yang belum dikerjakan LOO, dengan memperhitungkan persentase yang di dapat maka dilakukan perbandingan dengan target parameter KPI yang ada. Sehingga menghasilkan target KPI yang tercapai. Untuk melihat dari mana dapatnya persentase LOO yang sudah dilakukan, dapat dilihat untuk transaksi hasil sistem informasi TRM pada data detailnya. d). Inquiry Response Time Report KPI proses Inquiry Response Time pada departemen Call Center dapat dilihat pada Gambar 32.
80
Gambar 32 Tampilan Report KPI Proses Inquiry Response Time Gambar 32 memperlihatkan kalkulasi yang dihasilkan dari proses Inquiry Response Time yang ada pada bagian departemen Call Center. Berdasarkan gambar inquiry yang sudah di response ada 15 inquiry dari 17 inquiry yang masuk, dari hasil kalkulasi rata-rata inquiry response time yang masuk, ternyata lebih besar dari pada target parameter KPI, sehinggga hasil tujuan manajemen tidak tercapai. Untuk mengetahui bagaimana hasil rata-rata inquiry response time bisa lebih besar dari target parameter KPI, dapat dilihat pada detail data yang tersedia dari hasil transaksi sistem informasi TRM pada departemen Call Center. Report ini juga diperkuat dengan gambar grafik yang memperjelaskan kondisi jumlah inquiry yang belum di response, jumlah inquiry yang di response over dari 1 days dan yang before dari 1 days dengan memperlihatkan persentase dari total inquiry.
2. Report Marketing a). Rental Rate Report KPI proses Rental Rate pada departemen Marketing dapat di lihat pada Gambar 33.
81
Gambar 33 Tampilan Report KPI Proses Rental Rate Gambar 33 memperlihatkan kalkulasi yang dihasilkan dari proses Rental Rate yang ada pada bagian departemen Marketing. Berdasarkan gambar Rental Rate yang ada didapatkan rata-rata Rental Rate 13,71 USD, sedangkan untuk target parameter Rental Rate adalah 15 USD, sehingga menghasilkan target yang tidak tercapai. Untuk mengetahui dari mana mendapatkan total rental, total luasan area dan rata-rata Rental Rate dapat dilihat pada detail, yang merupakan report dari hasil transaksi yang terjadi di sistem informasi TRM. b). Occupancy Rate Report KPI proses Occupancy Rate pada departemen Marketing dapat dilihat pada Gambar 34.
82
Gambar 34 Tampilan Report KPI Proses Occupancy Rate Gambar 34 memperlihatkan persentase yang dihasilkan dari proses Occupancy Rate yang ada pada bagian departemen Marketing. Berdasarkan gambar Occupancy Rate yang ada hanya memperlihatkan persentase report dari hasil transaksi yang terjadi di sistem informasi TRM pada departemen Marketing. Disini dapat dilihat apakah target terpenuhi? Ternyata target tercapai, karena untuk class platinum melebihi dari target 55 %. c). Renewal Report KPI proses Renewal pada departemen Marketing dapat dilihat pada Gambar 35.
83
Gambar 35 Tampilan Report KPI Proses Renewal Gambar 35 memperlihatkan persentase yang dihasilkan dari proses Renewal yang ada pada bagian departemen Marketing. Berdasarkan gambar renewal ada 10 tenant yang masa kontraknya mau habis, sedangkan yang baru dilakukan renewal 6 tenant, sehingga menghasilkan persentase di bawah target parameter KPI yang membuat tujuan dari manajemen tidak akan tercapai. Untuk lebih jelas dan mendukung pengambilan simpulan tersebut bisa dilihat pada data detail.
3. Report Expense & Income a). Expense Expense merupakan pengeluaran buat divisi TRM, yang harus di bayar oleh bagian Finance Accounting, untuk melihat hasil Report KPI proses Expense yang dibandingkan antara expense actual dengan budget pada divisi TRM dapat dilihat pada Gambar 36.
84
Gambar 36 Tampilan Report KPI Proses Expense Gambar 36 menjelaskan kalkulasi yang dihasilkan dari proses Expense pada divisi TRM, yang membandingkan antara pengeluaran kenyataan dan pengeluaran rencana berdasarkan transaksi-transaksi yang terjadi pada sistem informasi TRM. b). Income Income merupakan pendapatan buat divisi TRM dari hasil rental leasing dan event, yang menjadi pemasukan buat manajemen perusahaan. Dimana pendapatan ini ada yang menjadi pendapatan bersih dan ada pendapatan yang akan digunakan lagi buat operasional perusahaan. Untuk melihat hasil Report KPI proses Income yang dibandingkan antara Income actual dengan budget pada divisi TRM dapat dilihat pada Gambar 37.
Gambar 37 Tampilan Report KPI Proses Income Gambar 37 menjelaskan kalkulasi yang dihasilkan dari proses Income pada divisi TRM, yang membandingkan antara pendapatan Leasing dan Event berdasarkan transaksi-transaksi yang terjadi pada sistem informasi TRM, yang merupakan pendapatan actual, yang akan dibandingkan dengan pendapatan leasing dan event berdasarkan budget. Dari grafik ini dapat dilihat apakah target dari manajemen tercapai atau tidak.
85
4.5 Pengujian Sistem Tenant Relation Management Pengujian sistem merupakan tahapan dimana semua kebutuhan sistem pada proses requirement telah terpenuhi di dalam aplikasi yang ada. Tujuan utama dari pengujian sistem adalah untuk memastikan bahwa elemen-elemen atau komponen-komponen dari sistem telah berfungsi sesuai dengan yang diharapkan. Metode pengujian yang diambil adalah metode pengujian Black Box. Pengujian Black Box merupakan metode perancangan data uji yang didasarkan pada spesifikasi perangkat lunak. Data uji dibangkitkan, dieksekusi pada perangkat lunak dan kemudian keluaran dari perangkat lunak di cek apakah sudah sesuai dengan yang diharapkan atau tidak. Pengujian dilakukan terhadap beberapa tahapan pengujian, yaitu : 1. Data Set Testing Data set testing merupakan pengujian yang dilakukan terhadap tipe data yang digunakan di dalam struktur database dengan proses, transaksi atau fungsi yang ada di dalam aplikasi sistem harus sama. 2. Unit dan Systems Testing Unit dan Systems test merupakan pengujian yang dilakukan terhadap proses, fungsi atau modul untuk keseluruhan informasi yang ada baik dari sisi tipe data, proses masing-masing unit dan proses sistem yang berhubungan dengan interaksi antara aplikasi dan database. 3. Integration Testing Integration test merupakan pengujian yang dilakukan untuk menguji relasi atau hubungan baik itu secara proses aplikasi ataupun dari sisi penggunaan datadata yang ada di dalam database antar proses atau modul dengan proses atau modul lainnya. 4. User Acceptance Testing User acceptance test merupakan pengujian akhir yang dilakukan antara pengembang sistem dengan user untuk melakukan pengujian sistem secara keseluruhan dari proses awal sampai proses akhir yang telah disepakati bersama pada tahap analisa kebutuhan.
86
4.6 Evaluasi Report Key Performance Indicator 1. Report Customer Service / Call Center Report Customer Service / Call Center yang berbasis target parameter merupakan tujuan dari pembuatan penelitian ini. Data-data transaksi yang terjadi pada sistem informasi divisi TRM, antara tenant dan Call Center, Control Room dan Marketing. Akan dibandingkan dengan target parameter KPI yang sudah ditetapkan oleh manajemen Gedung. Untuk departemen Call Center ada 4 kegiatan yang bisa dibuatkan laporan pengembangan DSS berbasis KPI yang akan digunakan oleh Manager divisi TRM atau Manajemen Perusahaan dalam memberikan target untuk kedepannya, kebijakan apa yang harus diperbaikan oleh Manager, melihat permasalah dan kendala yang ada. Untuk report Call Center yang berbasis KPI dapat dilihat pada Gambar 38.
Gambar 38 Report KPI Dashboard Departemen Customer Service Gambar 38 memberikan pandangan dan informasi sehingga membantu dalam pengambilan keputusan bagi Manager divisi Tenant Relation Management untuk memberikan target dan perbaikan kinerja pada departemen Call Center. Terutama untuk aktivitas-aktivitas : a. Complaint Status Dengan melihat laporan KPI Complaint Status ini, Manager dapat mengetahui : 1. Apakah target parameter KPI Complaint status tercapai.
87
2. Berapa complaint yang masuk dalam sehari, sebulan ataupun setahun. 3. Berapa persentase complaint yang dapat ditangani oleh departemendepartemen terkait. 4. Service yang kurang baik dari departemen mana terhadap tenant. 5. Paling banyak complaint di bagian departemen mana. 6. Perbaikan kinerja departemen yang berhubungan dengan pelayanan. b. Complaint Response Time Dengan melihat laporan KPI Complaint Response Time ini, Manager memiliki Gambaran dalam : 1. Apakah pelayanan terhadap tenan sudah memuaskan. 2. Apakah target parameter KPI Complaint Response Time tercapai. 3. Berapa rata-rata waktu complaint yang dapat direspon oleh departemen-departemen terkait. 4. Seberapa baik kerja dari departemen-departemen terkait. 5. Kenapa complaint tidak cepat dilakukan response. c. Inquiry Dengan melihat laporan KPI Inquiry ini, Manager memiliki Gambaran dalam : 1. Apakah target parameter KPI Inquiry tercapai. 2. Berapa persentase inquiry yang dapat ditangani oleh departemen Marketing. 3. Mengetahui tenant yang berpontesi dan peminatnya dari kalangan apa. d. Inquiry Response Time Dengan melihat laporan KPI Inquiry Response Time ini, Manager memiliki Gambaran dalam : 1. Apakah target parameter KPI Inquiry Response Time tercapai. 2. Berapa rata-rata waktu Inquiry yang direspons oleh departemen Marketing. 3. Mengetahui tenant yang berpontesi dan peminatnya dari kalangan apa.
88
2. Report Marketing Report KPI departemen Marketing yang berbasis target parameter merupakan laporan pengembangan DSS yang akan mendukung Manager divisi TRM dalam mengambil keputusan dan kebijakan. Data-data transaksi yang terjadi pada sistem informasi divisi TRM, antara tenant dan Marketing, akan dibandingkan dengan target parameter KPI yang sudah ditetapkan oleh manajemen Gedung. Untuk departemen Marketing ada 3 aktivitas yang bisa dibuatkan laporan pengembangan DSS berbasis KPI yang digunakan oleh Manager divisi TRM atau Manajemen Perusahaan dalam memberikan target untuk kedepannya, kebijakan apa yang harus diperbaikan oleh Manager, melihat permasalah dan kendala yang ada. Untuk report Marketing yang berbasis KPI dapat dilihat pada Gambar 39.
Gambar 39 Report KPI Dashboard Departemen Marketing Gambar 39 memberikan pandangan dan informasi sehingga membantu dalam pengambilan keputusan bagi Manager divisi Tenant Relation Management untuk memberikan target dan perbaikan kinerja pada departemen Marketing. Terutama untuk aktivitas-aktivitas :
89
a. Rental Rate Dengan melihat laporan KPI Rental Rate ini, Manager dapat mengetahui : 1. Apakah target parameter KPI Rental Rate tercapai. 2. Berapa besaran rental rate yang baik untuk tenant. 3. Berapa besaran luas area yang paling banyak dibutuhkan oleh tenant. b. Occupancy Rate Dengan melihat laporan KPI Occupancy Rate ini, Manager dapat mengetahui : 1. Apakah target parameter KPI Occupancy Rate tercapai. 2. Group mana yang lebih banyak di pilih oleh tenant. c. Renewal Dengan melihat laporan KPI Renewal ini, Manager dapat mengetahui : 1. Apakah target parameter KPI Renewal tercapai. 2. Jumlah tenant yang sudah mau habis masa kontraknya. 3. Berapa persentase tenant melakukan renewal.
3. Report Expense & Income Report KPI Expenses & Income yang berbasis target parameter merupakan laporan pengembangan DSS yang mendukung Manager divisi TRM dalam mengambil keputusan dan kebijakan. Data transaksi-transaksi yang berhubungan dengan keuangan terjadi pada sistem informasi divisi TRM baik sebagai pendapatan atau pengeluaran, antara tenant dengan Marketing, Call Center dan Tenancy akan dibandingkan dengan target parameter KPI budget yang sudah ditetapkan oleh manajemen Gedung. Untuk report KPI Expense dan Income bisa dibuatkan laporan pengembangan DSS berbasis KPI yang digunakan oleh Manager divisi TRM atau Manajemen Perusahaan dalam memberikan target untuk kedepannya, kebijakan apa yang harus diperbaikan oleh Manager. Untuk report Expense & Income yang berbasis KPI dapat dilihat pada Gambar 40.
90
Gambar 40 Report KPI Dashboard Expense & Income Gambar 40 memberikan pandangan dan informasi sehingga membantu dalam pengambilan keputusan bagi Manager divisi Tenant Relation Management untuk memberikan target dan perbaikan pendapatan dan pengeluaran. Informasi yang di dapat oleh Manager dari Report KPI Expense & Income adalah : a. Report KPI Expense Dengan melihat laporan KPI Expense ini, Manager dapat mengetahui : 1. Apakah target parameter KPI Expense tercapai. 2. Pengeluaran keuangan paling besar pada bulan apa. b. Report KPI Income Dengan melihat laporan KPI Income ini, Manager dapat mengetahui : 1. Apakah target parameter KPI Income tercapai. 2. Income terbesar pada bulan apa. 3. Besaran Income Leasing dan Income Event perbulannya. Dilihat dari informasi dan gambaran yang diberikan oleh sistem informasi divisi Tenant Relation Management dan sistem pengembangan DSS berbasis KPI, lebih mempermudah Manager dalam pengambilan keputusan. Dampak yang diberikan sistem adalah sebagai berikut : 1. Transaksi yang real-time yang terintegrasi ke semua department terkait.
91
2. Waktu yang dibutuhkan untuk pembuatan laporan KPI yang relative lebih cepat dan akurat. 3. Informasi yang berhubungan dengan departemen cepat di dapat, akurat dan dapat dipercaya. 4. Mempermudah sharing information antar departemen terkait. 5. Meningkatkan efektifitas dan efisiensi kerja dari karyawan yang terlibat dalam operasional
4.7 Implikasi Manajerial di Divisi Tenant Relation Management Dari hasil penelitian dapat diketahui bahwa pengembangan Decision Support Systems ini sangat membantu sekali buat manager ataupun pihak Manajemen dalam pengambilan keputusan untuk mencapai target yang diinginkan. Hasil penelitian menunjukan bahwa kepuasan dan response time yang cepat terhadap tenant merupakan target manajemen yang berdampak pada peningkatan kerja buat para karyawan khususnya di divisi TRM. Dengan
adanya
pengembangan
Decision
Support
Systems
ini
memberikan implikasi manajerial para pengambil kebijakan, dalam : 1. Pengontrolan kinerja
para
karyawan
lebih
cepat
diketahui dan
mendapatkan informasi yang akurat, sehingga mempercepat dalam pengambilan kebijakan dan keputusan untuk langkah selanjutnya. 2. Kontrol transaksi dilakukan dengan menggunakan aturan bahwa setiap transaksi yang ada harus sudah selesai dilakukan proses input ke dalam sistem pada hari yang sama (maksimal 1 hari). 3. Dokumen-dokumen yang ada sebagai pendukung proses yang dilakukan di dalam
sistem
harus
diketahui
oleh
pihak-pihak
terkait
dengan
mencantumkan paraf pada dokumen tersebut, contoh dokumen kontrak penyewa, yang dimana setiap referensi dokumen atau nomor dokumen harus tercatat di dalam sistem sebagai sesuatu yang harus di input. 4. Tindak lanjut / follow up kepihak-pihak terkait terhadap transaksi atau proses yang memiliki target penyelesaian, seperti proses renewal, complaint handling lebih cepat di kontrol.
92
93
BAB V SIMPULAN DAN SARAN
1. Simpulan Dari uraian mengenai Sistem Pengembangan Decision Support Systems berbasis Key Performance Indicator, maka dapat ditarik suatu simpulan : 1. Hasil
pengembangan
Decision
Support
Systems
berdasarkan
Key
Performance Indicator yang terintegrasi antar departemen sebagai bahan dalam pengambilan keputusan General Manager atau pihak manajemen seperti kapan harus melakukan review operasional Marketing, Engineering, House Keeping dan Security, kapan fokus terhadap penjualan area Platinum, Kapan Marketing harus mencari tenant baru dan sebagainya, dengan memberikan gambaran dan informasi keadaan yang terjadi untuk memudahkan dalam pengambilan tindakan dari target yang tidak tercapai. 2. Pengembangan Decision Support Systems berdasarkan Key Performance Indicator yang terintegrasi antar departemen sebagai acuan kontrol General Manager terhadap aktivitas yang terjadi di divisi Tenant Relation Management. 3. Adanya Sistem baru divisi Tenant Relation Management yang berdasarkan Key
Performance
Indicator
yang
terintegrasi
antar
departemen
mempermudah sharing data, informasi dan pembuatan laporan lebih cepat dan real time. 4. Dengan adanya analisis dan desain di divisi Tenant Relation Management sistem pengembangan Decision Support Systems berbasis Key Performance Indicator mempermudah dalam penggunaan sistem baru yang terintegrasi dan bisa sebagai panduan untuk pelaksanaan pembuatan report.
2. Saran Hasil
Pengembangan Decision Support Systems berdasarkan Key
Performance Indicator ini masih memiliki kekurangan dari segi integrasi dengan divisi lain, referensi dokumen masih ada yang mengikuti dokumen manual dan tidak memberikan keputusan akan hasil yang diperoleh terhadap
94
target parameter KPI yang ada. Sehingga untuk penelitian selanjutnya bisa mengembangkan lagi dan pengembangan sampai expert system untuk divisi Tenant Relation Management.
95
BAB IV DAFTAR PUSTAKA
Cai J., Liu X., Xiao Z., Liu J., 2009, Improving Supply Chain Performance Management : A Systemsatic Approach to Analyzing Interative KPI Accomplishment, Journal Elsevier Decision Support Systems 46, 512-512. Dharwiyanti S., Wahono R. S., 2003, Pengantar Unified Modeling language (UML), Kuliah Umum Ilmu Komputer.Com, Universitas Gunadarma. Djaelani A., 2009, Perencanaan Stratejik Pemasaran Jasa Pengelolaan Gedung Pada PT. Mutlicentral Aryaguna, Program Pascasarjana, Universitas Terbuka Jakarta. Mohemad R., Hamdan A. R., Othman Z. A., Noor N. M. M., 2010, Decision Support Systems (DSS) in Construction Tendering Processes, Terengganu, Malaysia, IJCSI International Journal of Computer Science Issues, Vol 7, Issue 2, No 1, March 2010. Parmenter D., 2007, Key Performance Indicators Developing, implementing, and Using Winning KPIs, Hoboken, New Jersey : John Wiley & Sons. Silfianti W., Pengenalan UML, Diktat Kuliah Ilmu Komputer.Com, Universitas Gunadarma. Rensfelt A., Winblad C. J., Lindman L., 2008, KPI’s Measuring and evaluting in order to increase logistic efficiency, Vaxjo Universitet School of management and Economics, Bachelor Thesis G3 in Business economics, 15 Logistics, FE3583, Spring semester 2008. Roy R., Chamorro F. M. Del R., Wegen B. Van, Steele A., A Framework to Create Performance Indicators in Knowledge Management. Satzinger J., 2007, Systems Analysis and Design in a Changing World. Thomson, USA. Sommerville I., 2011, Software Engineering Ninth Edition, Person Education, Addison-Wesley, USA. Sutono D., 2007, Sistem Informasi Manajemen, Pusat Pendidikan dan Pelatihan pengawasan Badan Pengawasan Keuangan dan Pembangunan, edisi keempat, Diklat Penjenjangan Auditor Ketua TIM., ISBN 979-3873-14-0.
96
Turban E., Aronson J. E., Liang T. P., 2005, Decision Support Systems and Intelligent Systems (Sistem Pendukung Keputusan dan Sistem Cerdas), Edisi 7 Jilid 1, Penerbit Andi Yogyakarta. Valverde R., 2011, A Risk Management Decision Support Systems for The Real Estate Industry, Montreal Canada, International Journal of Information and Communication Technology Research, ISSN-2223-4986, Volume 1 N0. 3, July 2011. Whitten J. L., Bentley L. D., Dittman K. C., 2004, Metoda Desain & Analisa Sistem, Edisi 6, Penerbit Andi Yogyakarta.
97
LAMPIRAN
98
Lampiran 1. Call Center Activity Diagram untuk Use Case Complaint Handling dan Complaint Update
99
Lampiran 2. Call Center Activity Diagram untuk Use Case Request Handling dan Request Update
100
Lampiran 3. Marketing Leasing Activity Diagram untuk Use Case Leasing Prospecting dan Prospecting Progress
101
Lampiran 4. Marketing Leasing Activity Diagram untuk Use Case LOO Leasing dan Renewal
102
Lampiran 5. Marketing Event Activity Diagram untuk Use Case Event Prospecting,Prospecting Progress Event dan LOO Event
103
Lampiran 6. Tenancy Activity Diagram untuk Use Case Facility Agreement, Tenant Update dan Tenant List Master
104
Lampiran 7. Overtime Activity Diagram untuk Use Case Overtime Request dan Overtime Approval
105
Lampiran 8. Complaint Handling Sequence Diagram
Lampiran 9. Complaint Update Sequence Diagram
106
Lampiran 10. Request Handling Sequence Diagram
Lampiran 11. Request Update Sequence Diagram
107
Lampiran 12. Leasing Prospecting Sequence Diagram
Lampiran 13. Prospecting Progress Sequence Diagram
108
Lampiran 14. Leasing LOO Sequence Diagram
Lampiran 15. Renewal Sequence Diagram
109
Lampiran 16. Event Prospecting Sequence Diagram
Lampiran 17. Event Progress Sequence Diagram
110
Lampiran 18. Event LOO Sequence Diagram
Lampiran 19. Facility Sequence Diagram
111
Lampiran 20. Tenant Update & Tenant List Sequence Diagram
Lampiran 21. Overtime Request Sequence Diagram
112
Lampiran 22. Overtime Update & Approval Sequence Diagram
