BAB IV PEMBAHASAN PENGEMBANGAN DECISION SUPPORT SYSTEMS BERBASIS KEY PERFORMANCE INDICATOR DI 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  Response 

/  Avg  Respons 

‘Achieve’ Else ‘Not Achieve’  Dengan 

:

Inquiry 

(24  jam)  Then 

     

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  pelaku-  pelaku 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  data-  data  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       da n  melakukan   proses   letter    of   offer    (LOO)    untuk proses  tenant  baru  atau  pun  perpanjangan  kontrak  sewa.   Merespon   semua   permintaan   dan   keluhan

3 

Marketing Event 

yang ditujukan ke departemen marketing leasing.  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 p 

yang

bertanggung

jawab       terhada

perubahan-perubahan       data       dari       tenant       da n  mendaftarkan     fasilitas-fasilitas     apa     saja     yang  digunakan  oleh  tenant.  Bertanggung  jawab  untuk  pembuatan    permintaan    pembelian    untuk    divisi  5 

Account Recievable 

Tanggung     jawab     organisasi    dalam     melakukan  proses    penagihan    atas     kontrak    event     ataupun  kontrak leasing yang sudah disetujui. 

6 

Account Payable 

Tanggung

organisasi dalam  melakukan 

jawab

proses    pembayaran    atas     permintaan    pekerjaan  ataupun barang.  7 

Control Room 

Bagian yang melakukan proses approval  terhadap  permintaan lembur. 

8 

TRM         Manager          Melakukan proses review terhadap laporan-laporan  /  dari       divisi       Tenant       Relation       Management.  General Manager  Melakukan entry parameter penentuan target. 

9 

Tenant 

Individu n 

atau

perusahaan

yang

memberika

informasi  keluhan terhadap  fasilitas  dan  pelayanan  serta  memberikan  informasi  permintaan  pelayanan  / permintaan fasilitas yang disediakan oleh gedung.  10  Non-Tenant 

Individu      atau      perusahaan      yang      memberika n  informasi          permintaan          mengadakan          sua tu 

11  Admin 

Individu     atau     suatu     bagian     yang     melakuka n

     

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  dari  tenant  yang  berhubungan  dengan  fasilitas   gedung,   operasional   gedung. Misalnya     keluhan     tenant     terhadap kebersihan, kebisingan dan sebagainya 

Entry Permintaan 

1. Call Center  (primer)  2. Control Room  (eksternal) 

Mendeskripsikan                      permintaan 1. Call Center  -  (primer)  permintaan baik  itu  dari tenant  seperti  2. Marketing event  permintaan   penambahan   daya   listrik, ijin    pekerjaan,    dan    lain    sebagainy

(eksternal) 

a  serta      dari      bukan      tenant      seperti permintaan  brosur  untuk  acara  event, 

3. Marketing Office  (eksternal) 

lokasi   kosong  untuk  perkantoran  dan  Entry Lembur 

Mendeskripsikan                         pencatata 1. Call Center  n  (Primer)  permintaan    lembur    dari    tenant    dan kontraktor  yang  melakukan  pekerjaan  2. Control Room  (Eksternal) 

di area gedung  Prospecting 

Mendeskripsikan pencatatan prospek 

Event 

individu        atau        perusahaan        yan

Marketing event  (primer) 

g  Prospecting 

berencana melakukan suatu event Mendeskripsikan                perkembangan Marketing event 

Progress 

prospecting event 

LOO Event 

Mendeskripsikan

(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

(primer) 

tenant  Prospecting 

Mendeskripsikan pencatatan prospek 

Office 

perusahaan yang berencana melakukan 

Marketing Leasing  (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 

(primer) 

Office  Perubahan       data  Mendeskripsikan tenant 

pencatatan

segala  Tenancy 

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 

     

lain sebagainya 

 

Entry        Formulir  Mendeskripsikan                        permintaa n  Pembelian  Barang (FPB) 

pembelian  barang  atau  jasa  dari  divisi Tenant Relation Management 

Target Divisi 

Mendeskripsikan

penetapan

target

operasional       untuk       divisi       Tenan t  Relation Management Entry            Master  Mendeskripsikan penginputan master Data 

data     yang    akan    digunakan    dalam sistem 

Update        Master  Mendeskripsikan        perubahan         dan Data 

pembaharuan terhadap master data 

45        (eksternal)      1. Tenancy (primer)       2. Account Payable      (eksternal)      Manager / General     Manager          Admin (Primer)            Admin (Primer)             

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 

digambarkan dalam use case diagram, seperti terlihat pada Gambar 6.

dapat 

     

46        TRM System 

    Leasing Prospecting

 

       

Prospecting Progress

 

 

Tenant Update

«Include»

  Marketing  Leasing

       

Facility Aggrement

 

 

Tenancy

 

 

 

 

LOO Leasing

 

Tenant List Master «Include»

 

 

Request Update

   

   

Renewal

«Include»

   

  Event Prospecting

«Include»

 

 

Request Handling

  

     

Prospecting Marketing Event

Progress

 

 

Complaint Handling

 

 

     

 

 

   

Call  Centre

Overtime Requset

 

   

LOO Event

  Overtime Update

 

 

Parameter Target

GM

   

 

  Complaint Update

Report Generation

 

 

      Overtime Approval

 

Control Room

 

 

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  informasi-  informasi   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           Leasing SubSystem 

Tenancy SubSystem 

 

  Leasing Prospecting

Prospecting Progress

 

 

 

Facility Aggrement

 

 

   

Tenant Update

   

   

Marketing Leasing

 

LOO Leasing

 

 

Tenant List Master

  Renewal

Tenancy

 

     

    Event SubSystem 

Customer Service SubSystem 

 

  Event Prospecting

 

 

Request Update

Complaint Handling

  Prospecting Progress

 

 

   

 

Marketing Event

 

 

         

 

      Request Handling         

         

Call Center

LOO Event

 

Complaint Update

   

    Operational SubSystem 

Overtime SubSystem 

   

   

Parameter Target

 

Overtime Requset

 

    Overtime Approval Report Generation

 

 

 

GM

 

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  masing-  masing 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   informasi-  informasi 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   Relation 

Management memiliki class-class seperti terlihat pada Gambar 9.

     

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.                                                                                                                                                     ActivityReserved

LOOEventClass

‐Prospecting_event_id

1

  ‐LOOApproval

1

1

‐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

‐ReservedStatus

1

+ E d i t ( )

            

   

           

‐Bill_date

‐GeneratedInvoice 1..*

‐base_amount ‐PPN_amount

1..*

‐due_date ‐Tenant_no ‐bill_type

‐Bill_sd ‐Bill_status

+get_invoice_no() +calc_total()

+Cacl_ppn_bill()

 

+posting_to_gl()

ss()

‐LOO_no

‐LOO_date

d

‐Lot

+get_tenant_id()

c

e

h

+Get_po_bo() +Get_date() +posting_to_gl()

 

1

1..*

              

‐po_id ‐Item_code ‐Item_desc ‐Measurement ‐qty_approved ‐item_prices ‐budget_code

+calc_total_po() +Calc_ppn() +calc_pph()

                                 nt

OvertimeRegister

 

+Calc_pph_bill()

   

+schedule_proce ‐OvertimeStatus ‐SheduleGenerate

     1..*

 

 

 

+Get_date() +Get_time() +Update()

D ‐T ena nt_ Na 1 me ‐PI C ‐RequestRegister ‐P hon e_n o ‐U nit_ +Get_date()

           

search_tenant()

Get_date_from()

‐Prospecting_i ‐Tenant_id

 

1

 

..*

 

  ‐Request_register ‐Request_dept_to ‐Request_detail

‐ ‐RequestStatus

RequestUpdate +

 

+

+Search_tenant_no_tenant() +Get_date() +Get_tim()

N

ena

 

1

nt e

e_id

G

e r a

 

+ U p d a

1

e _ s t a t u s _ p r o s p e c t i n g _ e v e n t )

  B

i l l i n g S c h e d

1

 

t

(

n_t

             

n

e

 

‐No

..*       ‐Overtime_status ena ‐Prospecting_id             nt_i                                                d                                                ‐Na ‐Overtime_remarks me ‐Co mp any ‐Ph one _no ‐Cel lula r_n o ‐Em ail

e

t

 

                              ‐Overtim

    

+Edit() +Get_request_id()

  O

 

 

‐Request_id ‐Request_date ‐Request_time ‐Request_type

+Save()

1

onT

vertime Approal & Update

                    

1..*                                                   1..*         1..*     +Get_date()

+

d

l

1..*         1..*

 

‐RequestRegister                                                                          +Get_time() +

e

u

    

‐Complaint_register ‐Complaint_dept ‐Complaint_detail +Search_tenant()

Requesthandling

+

1..*

cod e

Get_overtime_id()

‐Approval_dat

1..*

‐ComplaintRegister       +Get_date() +Get_time() +Save() ‐ 1..*       +Edit() +Get_complaint_id() +StatusUpdate()

1

nt_I

ScheduleGenerate

Get_time_to()

 

              

    

‐Complaint_type

ena

Get_time_from()

‐LOOApproval +Get_time() +Update() ‐Period_from +Schedule_generation() ‐Period_to

‐Complaint_id                                      ‐Complaint_id ‐Compalint_date                                   ‐Status ‐Complaint_time                                   ‐Remaks

‐ComplaintStatus

T

1

Overtime_time_from      ‐

        

Complaint Handling                   Complaint Update

‐ComplaintRegister

ena

+Calc_total_bill()

1..*

LOOClass

S

‐Bill_pph

1

Purchase order Detail

                                 +Save()

+Get_date_to()

+get_date()

ActivityReserved

‐

                                              

‐bill_curr

 

1

 

 

               

PurchaseOrder

‐PO_no ‐PO_date ‐request_id ‐Supplier ‐Supplier_tax_scheme

‐Approval_date                   

‐Period_from ‐Period_to 1 ‐bill_desc

1..*

‐Approved

       

‐T

.

LOOApproval

‐Overtime_id ‐Tenant_id ‐Overtime_date_from

 

‐Request_id ‐Item_code ‐Item_desc ‐Measurement ‐qty_requset ‐qty_approved ‐budget_code +Search_budget_code() +Search_item_code()

                

‐Schedule_id ‐Tenant_no ‐Bill_type

 

1..* Overtime

+get_schedule_id

()

1

1

*

1

‐Overtime_date_to ‐pph_amount ‐Overtime_time_to ‐Overtime_type

‐Bill_amount ‐Bill_ppn

‐status ‐Posting

.

1..*

1..* ule

      

1 1

    

‐Request_id ‐Request_approval +Get_date() +Update_purchase_Requisition()

Purchase Requisition Detail

‐Activity_event_id ‐Prospecting_event_id ‐Lot_event_selection

‐Invoice_no

‐PRApproval

+Get_request_id() +Get_date()

 

+Get_activity_event_id() +Get_date() +View_available_lot_event() +Add()

 

PRApproval

‐Request_id ‐Request_date ‐Request_user ‐Request_divisi ‐Requset_desc ‐status

1

 

Prospecting Event Progress

 

                                                      Purchase Requisition

‐Prospecting_event_id                             ‐activity_event_id ‐Prospecting_event_type                          ‐Activity_event_date ‐Prospecting_event_date                          ‐Activity_event_description ‐Prospecting_event_name                        +Add() ‐Prospecting_event_phone                       +Edit() ‐Prospecting_event_email                        +Save() ‐Prospecting_event_type ‐Prospecting_lcd ‐Prospecting_status                                                       1..* +Search_tenant_event() +Get_date() +Get_time() +View_prospecting_event_status() +Edit() +Save()

‐AddActivity

LOOEventApproval

‐Prospecting_event_id ‐ T e+get_tenant_id() n a n t Invoice _ i ‐Schedule_id d ‐invoice_date

   

ProspectingEvent                          Progressing Event Detail

   

   

       quest_id

                                 

 

‐Re

 

+Update()

‐Status ‐Remaks

                                                                             Gambar 13 Tenant Relation Management Class Diagram      4.3.4 Model Sequence Diagram  ‐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()

+Update_status_prospecting()

 

1

1

‐ReservedStatus

       

‐AddActivity

Prospecting

1

‐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..*

1

Prospecting Progress

‐Activity_id ‐Prospecting_id ‐Lot_selection

+Get_activity_id() +Get_date() +View_available_lot() +Add() +Edit() +Save()

1

Progressing Detail

‐activity_id ‐Activity_date ‐Activitt_description

1..*

+Add() +Edit() +Save()

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 

e. 

digambarkan dengan langkah-langkah seperti terlihat pada Lampiran 20.      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 transaksi-  transaksi   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   transaksi-  transaksi  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  data-  data  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  departemen-  departemen 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.