BAB 1

PENDAHULUAN

1.1 Latar Belakang

Saat ini perkembangan teknologi sudah berkembang dengan pesat. Semua

perusahaan dari skala kecil hingga besar memanfaatkan teknologi untuk efisiensi
sehingga informasi dapat diperoleh dengan cepat. Salah satu proses penting
dalam perusahaan yang sangat bergantung pada perolehan informasi adalah
proses pengambilan keputusan. Proses pengambilan keputusan yang tepat dan
cepat akan mendukung efisiensi dan efektivitas operasional perusahaan.
Mengambil keputusan merupakan bagian dari proses mempertimbangkan,
memahami, mengingat dan menalar tentang segala sesuatu (Dahlan, 2005).
Keputusan diambil dengan mengetahui dan merumuskan masalah dengan jelas,
kemudian pemecahan masalah tersebut harus didasarkan pemilihan alternatif
keputusan terbaik (Syamsi, 1995).
Salah satu proses manajemen yang dilakukan pada TI untuk pengambilan
keputusan yang lebih baik adalah Change management. Change management
merupakan sebuah proses untuk mengontrol dan mengkoordinasikan seluruh
perubahan pada TI, khususnya pada production environment. Dalam change
management, terdapat sebuah tim yang dibentuk khusus untuk menyetujui
Change Request (CR) dan menentukan prioritas atas perubahan yang telah
diajukan dengan melakukan review serta membuat jadwal untuk penerapan
perubahan yang telah disetujui.
Sebagai perusahaan yang bergerak di bidang layanan Teknologi Informasi,
PT XYZ juga merasakan pentingnya proses kontrol ini. Oleh karena itu,
dibentuklah Divisi Manage Operation yang bertugas mengelola dan
mengeksekusi permintaan perubahan atau Change Request (CR). Tim di dalam
divisi ini dinamakan Production Deployment Management (PDM). Tujuan dari
dibentuknya tim ini adalah untuk mengidentifikasi CR yang akan dijadwalkan.
Tim ini juga secara khusus memantau setiap perubahan TI yang dilakukan oleh

1
perusahaan tersebut. Kedepannya, tim ini akan terus melakukan review untuk
merekomendasikan perubahan TI apa yang tepat untuk perusahaan terkait.
Informasi terkait release CR, selain digunakan oleh Tim PDM, juga
diperlukan oleh Tim IT Operation Center (ITOC) untuk mendukung
operasionalnya. Departemen ITOC menggunakan data terkait CR dari sistem
PDM untuk memantau tingkat keberhasilan atau Success Rate (SR) yang dilihat
dari tingkat transaksi pada semua sistem layanan yang telah berjalan dan tersedia
bagi publik. Hal ini dilakukan untuk memastikan semua sistem layanan
senantiasa memberikan tingkat layanan yang memuaskan dan error free bagi
pelanggan.
Saat ini, sistem PDM sudah membuka akses bagi sistem internal lain yang
membutuhkan data terkait release CR menggunakan API. Namun, sistem lain
yang memanfaatkan data release, khususnya Departemen ITOC, masih belum
menggunakan data release yang tersedia secara maksimal dalam membuat
dashboard release yang informatif dan interaktif untuk mendukung pemantauan
SR oleh ITOC. Salah satu informasi penting yang belum tercakup dalam
dashboard release pada sistem ITOC adalah informasi terkait daftar release yang
bersifat kritikal yang dijadikan ITOC sebagai acuan dalam menentukan prioritas
pemantauan SR. Kendati tersedianya API untuk mengambil data yang
dibutuhkan untuk menghasilkan informasi release kritikal tersebut, sistem ITOC
belum dilengkapi dengan kemampuan untuk mengolah data release untuk
kemudian menghasilkan kategorisasi prioritas release.
Keterbatasan fungsionalitas pada sistem ITOC mengharuskan Tim ITOC
untuk memperoleh informasi daftar release kritikal secara manual dengan
mendatangi Tim PDM untuk memintanya melakukan pengolahan data release
dan menghasilkan informasi yang dibutuhkan. Pengolahan data oleh Tim PDM
juga masih dilakukan secara manual oleh analis sehingga cukup menyita waktu
dan menjadikan informasi tersebut tidak tersedia secara langsung. Selain itu
proses ini juga memiliki kemungkinan terjadinya human error karena bergantung
pada tingkat pemahaman analis dalam melakukan kategorisasi release
berdasarkan kriteria kategorisasi yang telah ditentukan Tim PDM.
Delay yang dialami Tim ITOC dalam akuisisi informasi release, khususnya
terkait daftar release yang bersifat kritikal, akan menghambat penentuan prioritas
pemantauan sehingga menghambat pendeteksian dan penanggulangan anomali

2
yang terjadi pada release yang tercermin pada penurunan SR. Pada akhirnya,
keterlambatan ini menyebabkan terjadinya penurunan layanan dan keluhan
pelanggan yang berujung pada penurunan kepuasan pelanggan.

---
Gambar 1.1 Dashboard Release ITOC Saat Ini

Manajer ITOC menyadari bahwa dibutuhkan sebuah sistem infomasi untuk

mendukung perolehan informasi terkait release yang lebih lengkap dan relevan
untuk membantu ITOC dalam menentukan prioritas pemantauan terhadap SR
dari release agar dapat menanggulangi anomali secara tepat waktu untuk
menjaga tingkat layanan dan kepuasan pelanggan. Berdasarkan kebutuhan
tersebut, gagasan yang disampaikan penulis adalah pengembangan sistem
informasi e-Reporting untuk Change Request Management pada sistem ITOC
yang berupa dashboard interaktif yang disertai dengan sistem pendukung
keputusan dengan kemampuan analisa untuk menghasilkan rekomendasi
peringkat prioritasi release berdasarkan kategorisasi severity dari release
menggunakan metode Analytic Hierarchy Process (AHP).
Penelitian terkait pengembangan sistem informasi e-Reporting pernah
dilakukan oleh (Saputra, Herdiansyah, & Udariansyah, 2019) dengan
menggunakan metode SDLC adaptif dengan pendekatan Rapid Application
Development (RAD) yang menghasilkan sistem e-Reporting berbasis android
untuk menyampaikan laporan terhadap kejadian yang ada di Kecamatan Buay
Madang. Hal yang sama juga pernah dilakukan oleh (Mambu, Rindengan, D, &
Karouw, 2016) menggunakan metode yang sama dan menghasilkan sistem e-
Reporting yang terbukti membantu masyarakat Manado dalam melaporkan
kejadian darurat dan membantu pemerintah untuk menerima setiap laporan dan
informasi dari masyarakat dengan lebih cepat, efektif dan efisien.
Berdasarkan penelitian tersebut, kami hendak mengembangkan sistem
informasi e-Reporting dengan menggunakan metode SDLC adaptif dengan
pendekatan prototyping dimana hasil yang diharapkan berupa sistem informasi e-
Reporting Change Request Management yang mampu membantu Departemen
ITOC pada PT XYZ dalam mendapatkan informasi terkait release CR yang lebih

3
 relevan secara cepat sehingga dapat mendukung pengambilan keputusan terkait
prioritasi pemantauan release dengan semakin tepat dan cepat kedepannya.

1.2 Rumusan Masalah

Berdasarkan latar belakang penelitian yang telah diuraikan di atas, dapat
dirumuskan masalah dalam penelitian ini yaitu bagaimana cara mengembangkan
sistem informasi e-Reporting yang mampu mendukung penentuan prioritas
pemantauan release CR untuk mendukung kelancaran operasional dan menjaga
tingkat kepuasan pelanggan pada Tim IT Operation Center (ITOC)?

1.3 Ruang Lingkup

Ruang lingkup pada penulisan skripsi ini dibatasi pada:

a. Penelitian dilakukan pada Tim Production Deployment Management (PDM)

sebagai penyedia data terkait CR dan Tim IT Operation Center (ITOC)
sebagai pemilik dari sistem informasi e-Reporting yang akan dikembangkan
pada PT XYZ.
b. Melakukan analisis terkait pengerjaan dan kategorisasi Change Request (CR)
pada Tim PDM.
c. Melakukan analisis terkait kebutuhan serta penggunaan informasi CR pada
Tim ITOC.
d. Melakukan pengembangan sistem informasi e-Reporting yang mencakup
halaman dashboard yang dilengkapi informasi pendukung keputusan berupa
rekomendasi peringkat prioritasi release menggunakan pemodelan Analytic
Hierarchy Process (AHP) untuk membantu dalam menentukan prioritas
pemantauan release CR bagi Tim ITOC pada PT XYZ.
e. Melakukan pengujian sistem informasi e-Reporting dengan menggunakan
data historis atau data dummy dari perusahaan.
f. Pengembangan sistem informasi e-Reporting hanya dilakukan sampai tahap
implementasi pengujian dan tidak sampai tahap Deployment dan
Maintenance.
g. Sistem informasi e-Reporting yang dikembangkan akan berbasis web.

1.4 Tujuan dan Manfaat

4
 1.4.1 Tujuan
Berdasarkan latar belakang diatas, maka tujuan yang hendak dicapai
dalam gagasan ini adalah mengembangkan sistem informasi e-Reporting
berbasis web yang mencakup halaman dashboard yang dilengkapi informasi
pendukung keputusan berupa rekomendasi peringkat prioritasi release
menggunakan pemodelan Analytic Hierarchy Process (AHP) pada sistem
ITOC di PT XYZ untuk menyediakan informasi terkait release CR yang lebih
relevan secara cepat sehingga dapat mendukung pengambilan keputusan
terkait prioritasi pemantauan release dengan semakin tepat dan cepat
kedepannya.

1.4.2 Manfaat
Berdasarkan tujuan yang hendak dicapai, maka pengembangan
gagasan ini diharapkan mempunyai manfaat sebagai berikut:
a. Bagi pengguna sistem ITOC, memberikan kemudahan dalam memperoleh
informasi terkait kategorisasi severity dan prioritasi release CR, terutama
daftar release yang bersifat kritial untuk dijadikan acuan dalam
menentukan prioritasi pemantauan terhadap release sehingga
meningkatkan kemampuan ITOC dalam mendeteksi dan menanggulangi
anomali untuk menjaga tingkat layanan dan menghindari keluhan
pelanggan untuk mencegah penurunan tingkat kepuasan pelanggan.
b. Bagi pejabat terkait, diharapkan dengan adanya sistem e-Reporting ini
dapat menyediakan informasi terkait Change Request untuk membantu
pengambilan keputusan untuk strategi perusahaan ke depan.
c. Bagi penulis, meningkatkan pengetahuan terkait pengembangan sistem e-
Reporting dan Change Request Management baik secara teori maupun
teknis.
d. Bagi peneliti lain, sebagai referensi dalam pembelajaran terkait sistem e-
Reporting dan Decision Support System.

1.5 Metodologi Penelitian

Metodologi penelitian skripsi ini terdiri dari metode pengumpulan data dan
metode pengembangan sistem.

5
1.5.1 Metode Pengumpulan Data
Metode pengumpulan data yang digunakan terdiri atas tiga tahapan
berikut:
a. Studi Pustaka
Penulis mencari informasi yang berasal dari buku dan berbagai
literatur terkait sistem e-Reporting, Change Request Management,
Decision Support System dan metode Analytic Hierarchy Process (AHP).
Sumber tersebut digunakan sebagai landasan teori dan alat bantu dalam
menganalisis.
b. Observasi
Dalam observasi ini, penulis melakukan pengamatan kondisi yang
sedang berjalan pada Tim PDM dan ITOC di PT XYZ dan
mengumpulkan informasi-informasi yang dibutuhkan dalam proses
pembuatan aplikasi melalui wawancara.
c. Wawancara
Untuk menjelaskan permasalahan dan mengumpulkan data yang
dibutuhkan untuk pengembangan dilakukan wawancara dengan project
manager dari Tim PDM.

1.5.2 Metode Pengembangan Sistem

Metode dan tahapan yang dilakukan untuk pengembangan aplikasi e-
Reporting mengacu pada System Development Life Cycle (SDLC) dengan
pendekatan adaptif (Satzinger, Jackson, & Burd, 2012), sebagai berikut:

a. Identifikasi (Identify), identifikasi permasalahan serta kebutuhan, dan

mendapatkan persetujuan untuk proses lebih lanjut.
Pada tahap ini, penulis melakukan wawancara dan observasi keadaan
sistem berjalan: mendengarkan penjelasan dari project manager dari Tim
PDM dan project manager pada PT XYZ mengenai Change Request dan
manajemen proses yang sedang berjalan di perusahaan. Setelah itu
dilanjutkan dengan pengajuan solusi pengembangan sistem informasi e-
Reporting dan mendapatkan persetujuan dari pihak PT XYZ.

6
b. Perencanaan (Plan), perencanaan dan pemonitoran proyek. Pada tahap ini
akan ditentukan apa yang akan dilakukan, bagaimana caranya, dan siapa
yang akan melakukan.
Pada tahap ini, penulis akan mengembangkan rencana dan menyusun
jadwal yang dibutuhkan untuk pengembangan sistem informasi e-
Reporting.

c. Mencari tahu (Discover), mencari dan memahami detail permasalahan

dan kebutuhan pengguna.
Dari hasil wawancara pada tahap identify, project manager mulai
menjelaskan fitur apa saja yang harus dimiliki oleh sistem e-Reporting
pada sistem ITOC secara spesifik dan sesuai dengan kebutuhan user.
Wawancara juga dilakukan dengan project manager dari Tim PDM untuk
mengumpulkan kriteria keputusan dan pembobotan kriteria yang akan
digunakan dalam pemodelan AHP untuk menghasilkan informasi
pendukung keputusan pada halaman dashboard release CR.

d. Perancangan (Design), perancangan komponen sistem yang mampu

memecahkan masalah dan memenuhi kebutuhan pengguna.
Perancangan sistem meliputi pemodelan workflow keseluruhan
aktivitas monitoring CR yang berjalan sesuai Standard of Procedure
(SOP), serta pemodelan rancangan sistem e-Reporting, halaman
dashboard release CR, dan pemodelan informasi pendukung keputusan
dengan Analytic Hierarchy Process (AHP) menggunakan diagram
Unified Modelling Language (UML).

e. Membangun, menguji, dan integrasi (Build, test, and integrate),

membangun sistem, melakukan pengujian, dan mengintegrasikan
komponen sistem.
Pada tahap ini akan dilakukan pengembangan dan pengujian terhadap
sistem e-Reporting. Pengembangan sistem akan menggunakan bahasa
pemrograman PHP dengan framework Code Igniter (CI) yang
mendukung model Model, View, Controller (MVC). Bahasa
pemrograman ini dipilih untuk menyesuaikan dengan sistem ITOC saat

7
 ini yang dikembangkan menggunakan bahasa pemrograman PHP dengan
framework CI.
Pengujian sistem yang dilakukan yaitu pengujian penerimaan user
atau user acceptance test (UAT). Pengujian penerimaan user digunakan
untuk mengetahui tanggapan user terhadap sistem e-Reporting dan
memastikan kesesuaian fitur sistem dengan kebutuhan user.
Sistem informasi yang telah dikembangkan nantinya akan
diintegrasikan dengan sistem ITOC saat ini sebagai penambahan pada
fitur pelaporan untuk melengkapi informasi yang tersedia pada halaman
dashboard release CR.

f. Penyelesaian (Complete), menyelesaikan pengujian sistem dan

memberikan solusi.
Pada tahap ini, akan dilakukan penyelesaian pengujian sistem dan
instalasi sistem informasi e-Reporting yang telah dikembangkan agar
tersedia untuk diakses oleh seluruh user pada tim untuk mendukung
operasional Tim ITOC pada PT XYZ.

Pada penelitian ini, tahapan yang dilakukan penulis hanya sampai

pada tahap Build and Test. Proses Integrate dan Complete tidak dijelaskan
dalam penelitian ini.

1.5.3 Metode DSS

Metode pemodelan informasi pendukung keputusan yang akan
digunakan adalah teknik AHP (Analytical Hierarchy Process).

AHP yang dikembangkan oleh Thomas Saaty, merupakan sebuah

struktur pemodelan untuk merepresentasikan permasalahan multi kriteria
(beberapa tujuan, beberapa sasaran) dengan sekumpulan kriteria dan alternatif
(pilihan) yang umum ditemukan dalam lingkungan bisnis (Turban, Sharda, &
Delen, 2015).
Teknik ini dipilih karena permasalahan membutuhkan output berupa
prioritas dari hasil pemberian ranking atau peringkat berdasarkan beberapa
kriteria yang telah dirumuskan.

8
1.6 Sistematika Penulisan

Secara garis besar, penulisan skripsi ini terbagi menjadi lima bab, dimana
masing-masing bab tersebut terbagi menjadi beberapa sub-bab dengan cakupan
yang lebih spesifik. Adapun pembahasan tiap bab dalam penulisan skripsi ini
adalah sebagai berikut:

BAB 1 PENDAHULUAN

Bab ini berisi latar belakang yang mendasari pembuatan

sistem informasi e-Reporting Change Request Management, ruang
lingkup, tujuan dan manfaat, metodologi penelitian yang digunakan
serta sistematika penulisan untuk menjelaskan pokok-pokok
pembahasan.

BAB 2 LANDASAN TEORI

Bab ini menjelaskan secara singkat teori-teori yang menjadi

landasan analisis dan perancangan sistem dalam pembuatan sistem
informasi e-Reporting Change Request Management ini. Teori-teori
tersebut didapat dengan melakukan studi pustaka sebagai landasan
dalam melakukan penelitian.

BAB 3 ANALISIS SISTEM BERJALAN

Bab ini membahas tentang informasi yang terkait dengan

perusahaan. Dari riwayat perusahaan, visi dan misi perusahaan,
struktur organisasi perusahaan dan peran yang terlibat dalam
perusahaan. Juga sistem yang sedang berjalan dan kebutuhan
informasi dalam perusahaan beserta dengan masalah yang sedang
dialami oleh perusahaan dan solusi yang ditawarkan untuk
menyelesaikan masalah.

BAB 4 PERANCANGAN DAN IMPLEMENTASI

Bab ini berisi penjelasan mengenai arsitektur dan rancangan

sistem informasi e-Reporting serta implementasi dan evaluasi sistem
informasi e-Reporting yang telah dibuat.

9
BAB 5 SIMPULAN DAN SARAN

Bab terakhir yang merupakan bab penutup berisi kesimpulan

yang diperoleh dari hasil pengembangan sistem informasi e-Reporting
serta saran-saran yang dapat membantu pengembangan lebih lanjut.

10
 BAB 2
LANDASAN TEORI DAN KERANGKA BERPIKIR

2.1. Teori Umum

2.1.1. Sistem Informasi

Sebuah sistem informasi dapat didefinisikan secara teknis sebagai
serangkaian komponen yang saling berhubungan yang mengumpulkan (atau
mengambil), memproses, menyimpan dan mendistribusikan informasi untuk
mendukung pembuatan keputusan dan melakukan kontrol pada sebuah
organisasi. (Laudon & Laudon, 2014).
Sedangkan menurut (Satzinger, Jackson, & Burd, 2012), sistem
informasi adalah satu rangkaian komponen komputer yang saling
berhubungan yang dapat mengumpulkan, memproses, menyimpan (biasanya
di dalam basis data) dan menyediakan output sebagai informasi yang
dibutuhkan bisnis.

2.1.2. SDLC
Menurut (Satzinger, Jackson, & Burd, 2012), SDLC adalah suatu
pengembangan sistem yang mengidentifikasi semua kegiatan yang diperlukan
untuk membangun, meluncurkan, dan memelihara sistem informasi. Biasanya
SDLC mencakup semua kegiatan yang merupakan bagian dari analisis
sistem, desain sistem, pemrograman, pengujian, dan pemeliharaan sistem
serta proses manajemen proyek lainnya yang diperlukan untuk keberhasilan
penyebaran sistem informasi.
Ada banyak pendekatan untuk SDLC dan banyak variasi untuk proyek
yang memiliki berbagai kebutuhan. Namun, ada serangkaian proses inti yang
selalu dibutuhkan, meskipun ada juga variasi proses inti yang lain. Setiap
proses direncanakan dan dilaksanakan untuk kemudian digabungkan menjadi
sebuah proyek. Berikut adalah enam proses inti yang diperlukan dalam
pengembangan aplikasi baru (Satzinger, Jackson, & Burd, 2012):
1. Identifikasi masalah atau kebutuhan dan mendapatkan persetujuan
untuk melanjutkan rencana pengembangan.

11
 2. Merencanakan dan memantau proyek terkait apa yang harus
dilakukan, bagaimana melakukannya, dan siapa yang melakukannya.
3. Menemukan dan memahami detail masalah atau kebutuhan.
4. Merancang komponen sistem yang memecahkan masalah atau
memenuhi kebutuhan.
5. Membangun, menguji, dan mengintegrasikan komponen sistem.
6. Menyelesaikan pengujian sistem dan mendeploy solusi.

2.1.3. Aktifitas Analisa Sistem

Aktivitas analisis (Satzinger, Jackson, & Burd, 2012):
1. Mengumpulkan informasi secara terperinci.
2. Menetapkan kebutuhan.
3. Menentukan prioritas kebutuhan.
4. Mengembangkan antarmuka pengguna.
5. Mengevaluasi kebutuhan dengan pengguna.

2.1.4. Analisa dan Desain Sistem

Analisa dan Desain Sistem sangat penting didalam pengembangan
sistem informasi. Dapat diibaratkan seperti seni dan ilmu pengetahuan untuk
membuat bangunan yang indah. Dalam skenario ini, terdapat pembeli yang
memiliki bayangan, dan ada pihak yang akan membangun gedung, serta ada
juga arsitek yang menjembatani antara pembeli dan pihak yang bertugas
untuk membangun.
Arsitek bertugas untuk menolong pembeli mengembangkan gedung apa yang
diinginkan, namun arsitek juga mengkomunikasikan spesifikasi gedung yang
diinginkan kepada pihak yang membangun. (Satzinger, Jackson, & Burd,
2012)
Untuk melakukan itu, arsitek menggunakan berbagai alat untuk
mengumpulkan kebutuhan pembeli. Lalu menyediakan informasi kepada
pembangun dengan berbagai spesifikasi dan instruksi, seperti cetak biru,
model skala, spesifikasi detail, dan inspeksi tempat secara langsung.
Begitu pula programmer, yang tidak bisa langsung mengerjakan kode
untuk membuat program. Sebelum mulai mengerjakan, rencana harus dibuat

12
 terlebih dahulu. Rencana-rencana ini meliputi mengetahui tujuan, memahami
detail, melakukan spesifikasi kebutuhan, sebelum memulai menulis kode.
Arsitek aplikasi harus memiliki kemampuan untuk memahami dan
mengetahui tujuan dari pihak yang mendanai proyek. Biasanya arsitek
software disebut sistem analis. Pada situasi dimana programmer memiliki
kecakapan yang setara dengan analis, akan lebih mudah untuk merekam jejak
pada detail tanpa menuliskannya. Namun untuk sebuah tim yang cukup besar,
penting untuk memiliki dokumentasi tertulis untuk membantu memahami,
mengumpulkan dan menentukan spesifikasi untuk mengembangkan
perangkat lunak.
Singkatnya, analisis sistem dan desain (SA&D) adalah tentang
menyediakan alat-alat dan teknik-teknik kepada pengembang untuk
mengkomunikasikan kebutuhan bisnis, mengetahui tujuan dan menemukan
solusi untuk menentukan langkah-langkah untuk membangun aplikasi,
mengkonfirmasi bahwa solusi memenuhi kebutuhan dan meluncurkan solusi
yang diwujudkan dalam aplikasi.
Analisis sistem terdiri dari aktivitas-aktivitas yang memungkinkan
seseorang memahami dan menentukan spesifikasi untuk mencapai sistem
yang baru. Analisis sistem menjelaskan secara terperinci "apa" yang harus
dilakukan sistem untuk memenuhi kebutuhan atau untuk menyelesaikan
masalah (Satzinger, Jackson, & Burd, 2012).
Desain sistem terdiri dari kegiatan-kegiatan yang memungkinkan
seseorang untuk menggambarkan secara rinci sistem yang memecahkan
kebutuhan. Kata operatif dalam kasus ini adalah "solves." Dengan kata lain,
desain sistem menjelaskan "bagaimana" sistem akan bekerja. Ini menentukan
secara rinci semua komponen sistem solusi dan bagaimana bersama-sama
bekerja untuk memberikan solusi yang diinginkan (Satzinger, Jackson, &
Burd, 2012).

2.1.5. Aktifitas Desain Sistem

Aktivitas desain menurut (Satzinger, Jackson, & Burd, 2012) :
1. Desain keadaan sekitar sistem.
2. Desain arsitektur aplikasi dan perangkat lunak.
3. Desain antarmuka pengguna.

13
 4. Desain antarmuka sistem.
5. Desain basis data.
6. Desain kontrol dan keamanan sistem

2.1.6. UML
Unified Modeling Language (UML) adalah seperangkat standar
konstruksi dan notasi model yang didefinisikan oleh Object Management
Group (OMG), sebuah organisasi standar untuk pengembangan sistem.
Dengan menggunakan UML, analis dan pengguna akhir dapat
menggambarkan dan memahami berbagai diagram spesifik yang digunakan
dalam proyek pengembangan sistem. Sebelum UML ada, tidak ada standar
yang ditetapkan untuk sebuah sistem, sehingga diagram dapat
membingungkan, dan mereka bervariasi dari perusahaan ke perusahaan (dan
dari buku ke buku) (Satzinger, Jackson, & Burd, 2012).

Gambar 2.1 Diagram UML

Sumber: (Satzinger, Jackson, & Burd, 2012)

2.1.7. Use Case Diagram

Use case adalah suatu kegiatan yang dilakukan sistem, biasanya
sebagai tanggapan atas permintaan oleh pengguna.

14
 Use case diagram merupakam model UML yang digunakan untuk
menunjukkan use case dan hubungannya dengan pengguna secara grafik.

Komponen dasar dari sebuah use case diagram meliputi:

1. Actor berbentuk orang. Seorang actor selalu di luar batas otomatisasi

(automation boundary) sistem tetapi dapat menjadi bagian dari bagian
manual dari sistem. Terkadang, actor untuk use case bukan orang, tetapi
bisa berupa sistem atau perangkat lain yang menerima layanan dari
sistem. Figur simple stick digunakan untuk merepresentasikan actor.
Figur tersebut diberi nama yang menjadi ciri khas peran yang dimainkan
actor.
2. Use case digambarkan dengan sebuah oval dengan nama use case di
dalamnya. Use case menggambarkan apa yang dilakukan actor di dalam
sistem.
3. Connecting line (garis penghubung) antara aktor dan use case
menunjukkan bahwa aktor terlibat dengan use case tersebut.
4. Automation boundary (batas otomatisasi), mendefinisikan batas antara
bagian yang terkomputerisasi dari aplikasi dan orang yang
mengoperasikan aplikasi, notasi ini ditampilkan dengan bentuk sebuah
persegi panjang yang memuat semua use case.

Gambar 2.2 Contoh Use Case Diagram

Sumber: (Satzinger, Jackson, & Burd, 2012)

15
2.1.8. Use Case Description
Use case description merupakan sebuah model tekstual yang berisi
daftar dan mendeskripsikan rincian proses untuk setiap use case.

Gambar 2.3 Contoh Use Case Description

Sumber: (Satzinger, Jackson, & Burd, 2012)

2.1.9. Activity Diagram

Menurut (Satzinger, Jackson, & Burd, 2012), suatu Activity Diagram
merupakan gambaran berbagai pengguna (atau sistem) kegiatan, orang yang
melakukan setiap kegiatan, dan aliran sekuensial dari kegiatan tersebut.
Activity Diagram merupakan salah satu diagram yang dapat
digunakan untuk mendeskripsikan sistem baru, menangani transaksi bisnis

16
atau requirement pengguna. Simbol - simbol yang digunakan Activity
Diagram diantaranya:
1. Oval
Merepresentasikan aktivitas individu dalam alur kerja.
2. Connecting arrow (Bentuk Panah penghubung)
Merepresentasikan urutan antara aktivitas.
3. Black circle denote (Bentuk Lingkaran hitam)
Menunjukkan awal dan akhir alur kerja.
4. Diamond (Bentuk Berlian)
Adalah titik keputusan di mana aliran proses akan mengikuti satu jalur
atau lainnya.
5. Syschronization bar (Bentuk Garis utuh tebal)
Adalah bilah sinkronisasi (pemisah), yang membagi jalan menjadi
beberapa jalur konkuren atau menggabungkan kembali jalur konkuren.
6. Swimlane heading (Judul swimlane)
Merepresentasikan agen yang melakukan kegiatan. Karena dalam alur
kerja memiliki agen yang berbeda (mis., Orang) melakukan langkah-
langkah berbeda dari proses alur kerja, simbol swimlane membagi
aktivitas alur kerja menjadi kelompok yang menunjukkan agen mana
yang melakukan aktivitas mana.

Gambar 2.4 Simbol dalam Activity Diagram

Sumber: (Satzinger, Jackson, & Burd, 2012)

17
 Gambar 2.5 Contoh Activity Diagram

Sumber: (Satzinger, Jackson, & Burd, 2012)

18
2.1.10. Domain Class Diagram
Menurut (Satzinger, Jackson, & Burd, 2012), Class Diagram adalah
diagram yang terdiri dari beberapa kelas (misalnya sekumpulan objek) dan
asosiasi di antara kelas-kelas. Class Diagram digunakan untuk menunjukkan
class objek pada sebuah sistem.
Domain model Class Diagram adalah diagram kelas yang hanya
mencakup kelas-kelas dari domain masalah (Satzinger, Jackson, & Burd,
2012).
Pada Class Diagram, persegi panjang merepresentasikan kelas, dan
garis-garis yang menghubungkan persegi panjang menunjukkan asosiasi
antara kelas. Simbol Domain Class Diagram adalah persegi panjang dengan
dua bagian. Bagian atas berisi nama kelas dan bagian bawah daftar atribut
kelas.

Gambar 2.6 Simbol dalam Class Diagram

Sumber: (Satzinger, Jackson, & Burd, 2012)

Gambar 2.7 Contoh Class Diagram

Sumber: (Satzinger, Jackson, & Burd, 2012)

2.1.11. System Sequence Diagram

Menurut (Satzinger, Jackson, & Burd, 2012), dalam pendekatan
berorientasi objek, aliran informasi dicapai melalui mengirim pesan baik ke

19
dan dari aktor atau bolak-balik antara internal objek. System Sequence
Diagram (SSD) digunakan untuk menggambarkan aliran informasi masuk
dan keluar dari sistem otomatis.
Seperti halnya diagram use case, gambar stick mewakili aktor —
seseorang (atau peran) yang berinteraksi dengan sistem. Dalam use case
diagram, aktor “menggunakan” sistem, tetapi penekanan pada SSD adalah
pada bagaimana aktor “berinteraksi” dengan sistem dengan memasukkan data
input dan penerimaan data output. Kotak berlabel: Sistem adalah objek yang
merepresentasikan keseluruhan sistem otomatis. Dalam SSD dan semua
diagram interaksi lainnya, analis menggunakan objek notasi alih-alih notasi
kelas. Dalam notasi objek, kotak mengacu pada objek individual, bukan kelas
dari semua objek serupa. Notasi hanyalah sebuah persegi panjang dengan
nama objek yang digarisbawahi. Titik dua sebelum digarisbawahi nama kelas
adalah bagian notasi objek yang sering digunakan tetapi opsional. Dalam
diagram interaksi, pesan dikirim dan diterima oleh individu objek, bukan oleh
kelas. Dalam sebuah SSD, satu-satunya objek yang disertakan adalah yang
mewakili seluruh sistem.
Jadi Sequence diagram digunakan untuk menggambarkan perilaku
pada sebuah skenario. Diagram ini menunjukkan sejumlah contoh objek dan
message (pesan) yang diletakkan diantara objek-objek ini di dalam use case.

Gambar 2.8 Contoh Sequence Diagram

20
 Sumber: (Satzinger, Jackson, & Burd, 2012)

2.1.12. Analisa dan Desain Sistem dengan UML

Gambar 2.9 Analisis dan Desain Menggunakan UML

Sumber: (Satzinger, Jackson, & Burd, 2012)

2.1.13. Pemrograman Web

21
 Pemrograman Web merupakan aktivitas untuk membuat halaman web atau
aplikasi web atau sistem informasi yang bekerja di platform web (Bramer, 2015).

2.1.14. HTML
HTML (Hypertext Markup Language) digunakan untuk menyusun konten
halaman web agar mudah ditangani oleh klien Web di sisi penerima (Wang,
2013).

HTML adalah bahasa yang memungkinkan informasi ditampilkan melalui

Internet oleh perangkat lunak standar, yang dikenal sebagai browser web, dengan
cara yang sangat fleksibel (Bramer, 2015).

2.1.15. CSS
Apabila HTML adalah bahasa yang menangani struktur halaman, cara
informasi sebenarnya disajikan (secara visual atau lainnya) kepada pengguna
akhir dikendalikan oleh browser Web yang menggunakan styling yang terkait
dengan halaman web. Styling dikodekan dalam aturan CSS (Cascading Style
Sheets) dan dilampirkan ke berbagai bagian halaman web. Styling biasanya
ditempatkan di file terpisah dari halaman web. Memisahkan styling halaman dari
struktur halaman memudahkan desainer web untuk menggunakan kembali
styling di halaman yang berbeda dan untuk menerapkan gaya visual yang
konsisten di seluruh situs web (Wang, 2013).

2.1.16. PHP
PHP adalah bahasa yang sangat kuat dan populer yang dirancang khusus
untuk skrip sisi server di Web (Wang, 2013).

2.1.17. Application Programming Interface (API)

Sebuah API menyediakan sebuah abstraksi untuk sebuah permasalahan dan
menspesifikasikan bagaimana clients harus berinteraksi dengan komponen
software yang mengimplementasi sebuah solusi bagi permasalahan tersebut. Pada
dasarnya, API mendefinisikan sebuah blok bangunan yang dapat digunakan ulang
yang memungkinkan bagian modular dari fungsionalitas untuk digabungkan
kedalam aplikasi pengguna akhir (Reddy, 2011).

22
2.1.18. Database
Database adalah kumpulan data yang saling terintegrasi, disimpan, dikelola
dan dikendalikan secara terpusat. Database biasanya menyimpan informasi
tentang lusinan atau ratusan kelas. Database dikelola dan dikendalikan oleh
sistem manajemen basis data (DBMS). DBMS adalah komponen perangkat lunak
sistem yang umumnya dibeli dan diinstal secara terpisah dari komponen
perangkat lunak sistem lainnya, seperti sistem operasi. Contoh sistem manajemen
basis data modern termasuk Microsoft SQL Server, Oracle, dan MySQL
(Satzinger, Jackson, & Burd, 2012).

2.1.19. MySQL
MySQL (My Structured Query Language) menurut situs resminya (Official
Website MySQL, 2019) adalah salah satu sistem basis data relation atau RDBMS
(Relational Database management System) yang mampu bekerja secara cepat dan
mudah digunakan. MySQL Community Edition didistribusikan gratis dibawah
lisensi GPL (General Public License).

2.1.20. Framework CodeIgniter

Codeigniter menurut situs resminya (Official Website CodeIgniter, 2019)
merupakan framework PHP yang kuat, dan tidak memakan banyak kapasitas.
Codeigniter ini dibangun dengan bahasa pemrogram PHP yang merupakan alat
untuk membuat web dengan fitur lengkap.
Framework ini dibuat oleh Rick Ellis, CEO Ellislab, Inc. Kelebihan dari
framework codeigniter jika dibandingkan dengan framework lain:
a. Gratis (Open-Source)
Codeigniter saat ini dikembangkan oleh British Columbia Institute of
Technology secara open-source sehingga bersifat terbuka atau gratis.
b. Berukuran kecil
Berukuran kecil merupakan suatu kelebihan framework yang menjadi
pertimbangan pengembang menentukan resource dalam eksekusi maupun
penyimpanannya.
c. Menggunakan konsep M-V-C

23
 Codeigniter menggunakan konsep M-V-C (Model-View-Controller) yang
memungkinkan pemisahan antara layer application-logic dan presentation.
Dengan konsep ini kode PHP, query Mysql, dan CSS dapat saling
dipisah-pisahkan sehingga ukuran file menjadi lebih kecil dan lebih mudah
untuk dilakukan pengembangan.
 Model adalah bagian kode program yang digunakan untuk
berhubungan dengan database MySQL sekaligus untuk
memanipulasinya (input-edit-delete).
 View yaitu komponen kode program berupa template atau PHP
untuk menampilkan data dan tampilan antarmuka aplikasi.
 Controller merupakan kode yang digunakan untuk mengontrol
aliran atau dengan kata lain sebagai pengontrol model dan view.

2.1.21. Testing
Testing adalah salah satu kegiatan pengembangan proyek. Testing adalah
bagian penting dari kegiatan implementasi. Berbagai jenis testing digunakan
dalam setiap proses inti. Testing adalah proses memeriksa suatu komponen,
subsistem, atau sistem untuk menentukan karakteristik operasionalnya dan
apakah mengandung cacat. Untuk melakukan pengujian, pengembang harus
memiliki standar yang ditetapkan dengan baik untuk persyaratan fungsional dan
nonfungsional. Dari persyaratan dan kebutuhan, pengembang mengembangkan
definisi yang tepat mengenai karakteristik operasional yang diharapkan dan yang
tidak. Pengembang dapat menguji perangkat lunak dengan meninjau konstruksi
dan komposisi atau dengan merancang dan membangun perangkat lunak,
menjalankan fungsinya, dan memeriksa hasilnya. Jika hasilnya menunjukkan
kekurangan, pengembang kembali melakukan perbaikan sampai kekurangan
diperbaiki atau cacat dihilangkan (Satzinger, Jackson, & Burd, 2012).

2.2. Teori Khusus

2.2.1. Change Management

Perubahan adalah sesuatu yang pasti dan akan terjadi. Begitu juga dengan
perusahaan atau organisasi yang dituntut untuk berubah dan terus menerus
melakukan penyesuaian agar terus bertahan dan semakin unggul dalam

24
 menjalankan bisnis. Untuk mencapai itu, perusahaan harus mengetahui strategi
perubahan yang tepat dan pelaksanaannya terus berkelanjutan.
Menurut (Jerald Greenberg, 2008), perubahan merupakan transformasi secara
terencana atau tidak terencana yang terjadi di dalam struktur organisasi, teknologi
dan atau pekerja sebagai sumber daya manusia.
Menurut (Stephen P. Robbins, 2002), manajemen adalah proses untuk
menyelesaikan aktivitas secara efisien dan efektif melalui orang lain. Efisiensi
menunjukkan hubungan antara input dan output dengan mencari biaya sumber
daya minimum. Efektif menunjukkan makna pencapaian tujuan yang telah
ditetapkan sebelumnya.
Manajemen perubahan adalah suatu proses yang dilakukan sistematis dalam
menerapkan pengetahuan, sarana dan sumber daya yang diperlukan dalam rangka
mempengaruhi perubahan pada orang yang akan terkena dampak dari proses
tersebut (Rebecca Potts, 2004).

2.2.2. Dashboard

Dashboard memberikan tampilan visual atas informasi penting yang

dikonsolidasi dan disusun pada sebuah layar tunggal sehingga informasi tersebut
dapat diterima dalam sekejap dengan satu tatapan dan dapat ditelusuri lebih
dalam dengan mudah (Turban, Sharda, & Delen, 2015).

2.2.3. Decision Support System (DSS)

Decision Support System (DSS) diidentifikasi sebagai sebuah sistem yang

ditujukan untuk mendukung pembuat keputusan manajerial dalam situasi
keputusan semi terstruktur dan tidak terstruktur. DSS dimaksudkan untuk
melengkapi dan memperluas kapabilitas pembuat keputusan, tetapi tidak untuk
menggantikan penilaian mereka. Secara formal, sebuah DSS merupakan sebuah
pendekatan (atau metodologi) untuk mendukung pengambilan keputusan
(Turban, Sharda, & Delen, 2015).

2.2.4. Analytic Hierarchy Process (AHP)

Analytic Hierarchy Process (AHP) yang dikembangkan oleh Profesor

Thomas Saaty pada tahun 1980 memungkinkan penataan keputusan secara hirarki
(untuk mengurangi kerumitannya) dan menunjukkan hubungan antara tujuan

25
(atau kriteria) dan alternatif-alternatif yang mungkin. Keunggulan terbesar dari
metode ini yaitu AHP memungkinkan penyertaan dari hal yang tak berwujud
(intangibles) seperti pengalaman, preferensi subjektif dan intuisi, dalam suatu
cara yang logis dan terstruktur (Mu & Pereyra-Rojas, 2017).

Para pembuat keputusan menggunakan AHP untuk menguraikan sebuah

masalah pengambilan keputusan kedalam kriteria dan alternatif-alternatif yang
relevan. AHP memisahkan analisis dari kriteria dari alternatif, yang membantu
pembuat keputusan untuk berfokus pada bagian-bagian kecil yang dapat dikelola
dari masalah (Turban, Sharda, & Delen, 2015).

Untuk menjelaskan metode ini, (Mu & Pereyra-Rojas, 2017) menggunakan

contoh sederhana: Tujuan kami adalah membeli sebuah mobil baru. Pembelian
kami didasarkan pada kriteria yang berbeda seperti biaya, kenyamanan, dan
keamanan. Kita dapat mengevaluasi beberapa alternatif tetapi kita asumsikan
bahwa kita hanya memiliki dua: Car 1 dan Car 2. Untuk menganalisa keputusan
membeli sebuah mobil menggunakan AHP, kita harus mengikuti langkah-

langkah berikut:

1. Mengembangkan sebuah model untuk keputusan: Pecah keputusan menjadi

sebuah hierarki atas tujuan, kriteria, dan alternatif.

Gambar 2.10 Hirarki Keputusan untuk Membeli Sebuah Mobil

Sumber: (Mu & Pereyra-Rojas, 2017)

26
2. Menurunkan prioritas (bobot) untuk kriteria: Tingkat kepentingan kriteria
dibandingkan secara berpasangan dengan tujuan yang diinginkan untuk
menurunkan bobotnya. Kemudian dilakukan pemeriksaan konsistensi dari
penilaian; yaitu sebuah review dari penilaian yang dilakukan untuk
memastikan sebuah tingkat konsistensi yang wajar dalam hal proporsionalitas
dan transivitas.
Tidak semua kriteria memiliki tingkat kepentingan yang sama. Oleh
karena itu, pada langkah ini akan dilakukan penurunan prioritas relatif
(bobot) dari kriteria. Disebut relatif karena prioritas kriteria yang didapat
diukur berkenaan dengan setiap kriteria lainnya.

Tabel 2.1 Skala Perbandingan Berpasangan Saaty

Sumber: (Mu & Pereyra-Rojas, 2017)

Prioritas relative dari setiap kriteria berkenaan dengan kriteria lainnya

diturunkan menggunakan sebuah skala numerik untuk perbandingan yang
dikembangkan oleh Thomas Saaty (Tabel 2.1).

27
Tabel 2.2 Matriks Perbandingan Berpasangan dengan Penilaian Intensitas

Sumber: (Mu & Pereyra-Rojas, 2017)

Setiap sel pada matriks perbandingan akan memiliki sebuah nilai dari
skala numerik pada Tabel 2.1 untuk mencerminkan preferensi relatif (atau
disebut juga penilaian intensitas atau penilaian) dalam setiap pasangan yang
telah dibandingkan.
Sebagai contoh, jika kita menganggap bahwa biaya (cost) lebih penting
(strongly more important) daripada faktor kenyamanan (comfort), sel
perbandingan biaya-kenyamanan (cost/comfort) akan diisi nilai 7 dan sel
kenyamanan-biaya (comfort/cost) akan berisi timbal balik 1 / 7 = 0,143.
Begitu juga, jika kita merasa bahwa keamanan (safety) lebih penting
(moderately more important) daripada kenyamanan (comfort), sel
keselamatan-kenyamanan (safety/comfort) akan berisi nilai 3 dan sel
keselamatan-kenyamanan (comfort/ safety), akan memiliki timbal balik 1/3 =
0,333. Setelah semua penilaian ini dimasukkan pada matriks perbandingan
berpasangan, didapat hasil yang ditunjukkan pada Tabel 2.2.
Selanjutnya kita perlu menghitung keseluruhan prioritas atau bobot dari
kriteria dengan menggunakan metode perkiraan (approximate method).
Metode perkiraan membutuhkan normalisasi dari matriks perbandingan, yang
didapat dengan, menambahkan nilai di setiap kolom (Tabel 2.3). Selanjutnya,
bagi setiap sel dengan total dari kolom (Tabel 2.4).

28
Tabel 2.3 Matriks Perbandingan Berpasangan dengan Penilaian Intensitas
dengan Kolom Total (Sum)

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.4 Matriks Ternormalisasi

Sumber: (Mu & Pereyra-Rojas, 2017)

Dari matriks yang ternormalisasi ini, kami memperoleh prioritas

keseluruhan atau final dengan hanya menghitung nilai rata-rata dari setiap
baris (misal, untuk baris biaya (cost) : 0,677 + 0,636 + 0,692) / 3 = 0,669).

29
 Tabel 2.5 Perhitungan Prioritas: Rata-Rata Baris

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.6 Tampilan Hasil: Penilaian Asli dan Prioritas

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.6 menunjukkan matriks perbandingan dengan penilaian asli

bersama dengan prioritas yang dihitung. Berdasarkan hasil pada Tabel 2.6,
jelas terlihat bahwa untuk contoh ini, kami memberikan tingkat kepentingan
yang lebih untuk kriteria biaya (0,669), diikuti oleh keamanan (0,243). Faktor
kenyamanan memiliki bobot minimum (0,088) dalam keputusan pembelian
kami.

3. Konsistensi
Karena nilai numerik diturunkan dari preferensi subjektif dari invididu,
inkonsistensi menjadi tidak mungkin untuk dihindari dalam matriks akhir dari
penilaian. AHP menghitung sebuah rasio konsistensi / Consistency Ratio
(CR) untuk mengetahui seberapa banyak inkonsistensi yang dapat diterima.
Perhitungan ini membutuhkan matrik random (acak). Matriks acak adalah
matriks yang penilaiannya dimasukkan secara acak dan oleh karenanya
diharapkan sangat tidak konsisten. Lebih spesifik, Random-like matrix Index
(RI) adalah Consistency Index (CI) rata-rata dari 500 yang diisi secara acak
dalam matriks. Saaty memberikan nilai RI yang telah dihitung untuk matriks
dengan ukuran yang berbeda seperti yang ditunjukkan pada Tabel 2.7.

30
 Tabel 2.7 Index Konsistensi untuk Sebuah Matriks Random

Sumber: (Mu & Pereyra-Rojas, 2017)

Dalam AHP, rasio konsistensi didefinisikan sebagai CR di mana CR =

CI / RI. Saaty menunjukkan bahwa rasio konsistensi (CR) 0,10 atau kurang
dapat diterima untuk melanjutkan analisis AHP. Jika rasio konsistensi lebih
besar dari 0,10, maka perlu untuk merevisi penilaian untuk menemukan
penyebab ketidakkonsistenan dan memperbaikinya.
Karena perhitungan rasio konsistensi mudah dilakukan oleh program
komputer, kami membatasi diri di sini untuk menghasilkan estimasi nilai ini
sebagai berikut:
a) Mulailah dengan matriks yang menunjukkan perbandingan penilaian
dan prioritas turunan (Tabel 2.6).
b) Gunakan prioritas sebagai faktor (bobot) untuk setiap kolom seperti
yang ditunjukkan pada Tabel 2.8.
c) Kalikan setiap nilai pada kolom pertama dari matriks perbandingan
dalam Tabel 2.8 dengan prioritas kriteria pertama (yaitu 1.000 x
0,669 = 0,669; 0,143 x 0,669 = 0,096; 0,333 x 0,669 = 0,223) seperti
yang ditunjukkan pada kolom pertama dari Tabel 2.9; kalikan setiap
nilai di kolom kedua dari prioritas kriteria kedua; lanjutkan proses ini
untuk semua kolom dari matriks perbandingan (dalam contoh kami,
kami memiliki tiga kolom). Tabel 2.9 menunjukkan matriks yang
dihasilkan setelah proses ini selesai.

31
 Tabel 2.8 Prioritas sebagai Faktor

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.9 Perhitungan dari Kolom Berbobot (Weighted Columns)

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.10 Perhitungan dari Jumlah Berbobot (Weighted Sum)

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.11 Perhitungan dari λmax

Sumber: (Mu & Pereyra-Rojas, 2017)

d) Tambahkan nilai dalam setiap baris untuk mendapatkan satu set nilai
yang disebut jumlah berbobot (weighted sum) seperti yang
ditunjukkan pada Tabel 2.10.

32
 e) Bagi elemen-elemen dari vektor penjumlahan tertimbang (diperoleh
pada langkah sebelumnya) dengan prioritas yang sesuai dari setiap
kriteria seperti yang ditunjukkan pada Tabel 2.11. Hitung rata-rata
dari nilai dari langkah sebelumnya; nilai ini disebut λmax.
λmax = (3.014 + 3.002 + 3.005) /3 = 3.007
f) Sekarang kita perlu menghitung indeks konsistensi (CI) sebagai
berikut:
C.I. = (λmax - n) / (n – 1)
dimana n adalah jumlah elemen yang dibandingkan (dalam contoh
kita n = 3).
Sehingga,
C.I. = (λmax - n) / (n – 1) = (3.007 – 3) / (3 -1) = 0.004

g) Sekarang kita dapat menghitung rasio konsistensi, yang didefinisikan

sebagai:
CR = CI/ RI
Sehingga,
CR = CI/ RI = 0004/ 0.58 = 0.006
Karena nilai 0,006 untuk proporsi CR inkonsistensi kurang dari 0,10, kita
dapat mengasumsikan bahwa matriks penilaian cukup konsisten sehingga
dapat melanjutkan proses pengambilan keputusan menggunakan AHP.

4. Menurunkan prioritas lokal (preferensi) untuk setiap alternatif: Turunkan

prioritas dari alternatif dalam hubungannya dengan setiap kritera secara
terpisah (mengikuti sebuah proses yang serupa dengan langkah sebelumnya,
membandingkan alternatif secara berpasangan dengan setiap kriteria). Periksa
dan sesuaikan konsistensi sesuai kebutuhan.

Pertanyaan Perbandingan 1: Sehubungan dengan kriteria biaya, alternatif

mana yang lebih disukai: Car 1 atau Car 2?

Tabel 2.12 Perbandingan sehubungan dengan biaya

Sumber: (Mu & Pereyra-Rojas, 2017)

33
 Tabel 2.13 Preferensi sehubungan dengan biaya

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.14 Hasil sehubungan dengan biaya

Sumber: (Mu & Pereyra-Rojas, 2017)

Pertanyaan Perbandingan 2: Sehubungan dengan kriteria kenyamanan,

alternatif mana yang lebih disukai: Car 1 atau Car 2?

Tabel 2.15 Perbandingan sehubungan dengan kenyamanan

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.16 Preferensi sehubungan dengan kenyamanan

Sumber: (Mu & Pereyra-Rojas, 2017)

34
Tabel 2.17 Hasil sehubungan dengan kenyamanan

Sumber: (Mu & Pereyra-Rojas, 2017)

35
Pertanyaan Pembanding 3: Sehubungan dengan kriteria keselamatan,
alternatif mana yang lebih disukai: Car 1 atau Car 2?

Tabel 2.18 Perbandingan sehubungan dengan keselamatan

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.19 Preferensi sehubungan dengan keselamatan

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.20 Hasil sehubungan dengan keselamatan

Sumber: (Mu & Pereyra-Rojas, 2017)

Sebagaimana ditunjukkan sebelumnya, prioritas (preferensi) dari

alternatif, sehubungan dengan setiap kriteria, disebut prioritas lokal (atau
preferensi). Ringkasan prioritas lokal untuk setiap alternatif ditunjukkan di
bawah ini:

36
Tabel 2.21 Prioritas Lokal (atau preferensi) dari alternatif sehubungan dengan
masing-masing kriteria

Sumber: (Mu & Pereyra-Rojas, 2017)

5. Menurunkan prioritas keseluruhan (sintesis model): Semua prioritas alternatif

yang didapat akan digabungkan sebagai sebuah total berbobot (weighted
sum), untuk memperhitungkan bobot dari setiap kritera, untuk menciptakan
prioritas keseluruhan dari alternatif. Alternatif dengan prioritas keseluruhan
tertinggi merupakan pilihan yang terbaik.
Kami memulai perhitungan prioritas keseluruhan menggunakan
prioritas lokal dari setiap alternatif sebagai titik awal (Tabel 2.21).
Selanjutnya, kita perlu mempertimbangkan bobot masing-masing
kriteria (dari Tabel 2.6) dan untuk tujuan ini dimasukkan dalam tabel seperti
yang ditunjukkan pada Tabel 2.22.
Sebagai contoh, kriteria biaya memiliki prioritas (atau bobot) 0,669
dan Car 1 memiliki prioritas lokal (atau preferensi) 0,875 relatif terhadap
biaya; oleh karena itu, prioritas berbobot, sehubungan dengan biaya, dari Car
1 adalah: 0,669 x 0,875 = 0,585.
Diperlukan perhitungan yang serupa untuk mendapatkan prioritas
bobot Car 1 sehubungan dengan kriteria kenyamanan dan keamanan. Matriks
yang dihasilkan ditunjukkan pada Tabel 2.23. Akhirnya, prioritas keseluruhan
Car 1 diperoleh dengan menambahkan hasil ini di sepanjang baris. Prosedur
ini diulang untuk setiap alternatif yang dievaluasi. Prioritas keseluruhan dari
alternatif ditunjukkan pada kolom paling kanan dari Tabel 2.23.

37
 Tabel 2.22 Persiapan untuk menimbang prioritas

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.23 Kalkulasi semua prioritas

Sumber: (Mu & Pereyra-Rojas, 2017)

Perhitungan untuk setiap alternatif ditunjukkan di bawah dan hasilnya

disajikan pada Tabel 2.24. Proses ini disebut sintesis model (lihat Tabel 2.24).
Dengan kata lain:
Prioritas keseluruhan dari Car 1: 0.875 x 0.669 + 0.167 x 0.08 + 0.100 x
0.243 = 0.624
Prioritas keseluruhan dari Car 2: 0.125 x 0.669 + 0.833 x 0.088 + 0.900 x
0.243 = 0.376

Tabel 2.24 Sintesis dari Model

Sumber: (Mu & Pereyra-Rojas, 2017)

38
 Sekarang kita dapat membuat daftar alternatif yang dipesan
berdasarkan prioritas atau preferensi keseluruhannya sebagai berikut:
Tabel 2.25 Hasil Prioritas Keseluruhan dari Alternatif

Sumber: (Mu & Pereyra-Rojas, 2017)

Dengan kata lain, berdasarkan pentingnya (atau bobot) setiap kriteria

pembelian (biaya, kenyamanan, dan keamanan), Car 1 lebih disukai (prioritas
keseluruhan = 0,624) dibandingkan dengan Car 2 (prioritas keseluruhan =
0,376).

6. Melakukan analisis sensitivitas: Sebuah studi tentang bagaimana perubahan

pada bobot kriteria dapat mempengaruhi hasil akan dilakukan untuk
memahami alasan (rasionale) dibalik hasil yang didapat.

Tabel 2.26 Skenario Asli— Sintesis Model

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.26 adalah sistensis model asli dimana opsi yang paling disukai adalah
Car 1 (0.624).

39
 Tabel 2.27 Skenario kedua: semua kriteria memiliki bobot yang sama

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.28 Skenario ketiga: bobot biaya mengarah ke preferensi yang sama dari
alternatif

Sumber: (Mu & Pereyra-Rojas, 2017)

Tabel 2.27 menunjukkan kasus di mana ketiga kriteria memiliki bobot

yang sama (0,333). Dalam skenario kedua ini, pilihan terakhir tidak lagi
memiliki Car 1 tetapi Car 2 (0,619) sebagai pilihan terbaik. Ini karena Car 2
menang di semua kriteria kecuali untuk biaya. Dengan menurunkan bobot
biaya (dari 0,669 dalam skenario asli ke 0,333 pada tahap kedua), kerugian
biaya tidak terlihat. Ini juga menunjukkan bahwa kedua alternatif sama-sama
disukai ketika bobot biaya dalam kisaran 0,333-0,699. Untuk menghitung
titik impas kita dapat mencoba bobot yang berbeda untuk biaya dan
menemukan bahwa ketika bobot biaya sekitar 0,5 dari keseluruhan kriteria,
Car 1 dan Car 2 memiliki preferensi yang sama untuk tujuan praktis. Artinya,
kedua alternatif sama-sama disukai seperti yang ditunjukkan pada Tabel 2.28.

40
7. Membuat keputusan akhir: Berdasarkan hasil sintesis dan analisis sensitivitas,
sebuah keputusan dapat dibuat.
Menganalisis hasil analisis sensitivitas (Tabel 2.26, 2.27 dan 2.28).
Dari analisis ini, kami dapat menyatakan rekomendasi akhir kami sebagai
berikut: Jika pentingnya biaya lebih dari 50% dari keseluruhan kepentingan
kriteria dalam keputusan, alternatif terbaik adalah Car 1 (Tabel 2.26); namun,
jika pentingnya biaya jauh lebih kecil dari 50%, Car 2 adalah keputusan
terbaik (Dari Tabel 2.27 dan 2.28).

41
2.3. Literature Review

Tabel 2.29 Literature Review Beberapa Penelitian terkait E-Reporting dan AHP

No Peneliti Judul/Topik Metode Hasil Limitasi / Penelitian

. Selanjutnya
1 Agil Saputra, Rancang Bangun Metode pengumpulan data Hasil yang didapatkan adalah
Muhammad Aplikasi E- dilakukan dengan wawancara, terbentuknya sebuah prototype
Izman Reporting observasi dan studi pustaka. atau perangkat lunak e-reporting
Herdiansyah Layanan Metode pengembangan berrbasis android yang dapat
dan Devi Masyarakat sistem dilakukan dengan digunakan sebagai sarana untuk
Udariansyah Kecamatan Buay Rapid Application menyampaikan laporan terhadap
Madang Berbasis Development (RAD). kejadian yang ada di Kecamatan
Android Buay Madang.
2 Roviana H. Dai, Rancang Bangun Metode yang digunakan Sistem yang dibangun berbasis
Lillyan Aplikasi E- dalam penelitian ini mengacu php dan mysql. Sistem
Hadjaratie dan Report pada metode pengembangan menyediakan media informasi
Nuzran Pengaduan sistem prototyping. data status laporan pengaduan
Firmansyah Masyarakat masyarakat yang berbasis pesan
Bouti singkat / sms yang sudah

42

3 Supanji Development Penelitian dilakukan dengan
Setyawan, Model of E- empat tahap sebagai berikut:
Nuwun Priyono Budgeting and E- (1) tahap studi pendahuluan
dan Chaidir Reporting System yaitu merancang model
Iswanaji on the konseptual berdasarkan teori
Management of dan studi lapangan; (2) tahap
Village Fund pengembangan model dengan
Finance merancang desain model; (3)
tahap validasi internal melalui cepat dan dapat mengurangi
Focus Group Discussion
(FGD) dengan rekan dan
pakar dan uji coba terbatas;
(4) tahap uji coba ekstensif
model dan model penyebaran
model akhir
direkomendasikan.
43
tergolong bisa
dijangkau oleh seluruh
masyarakat pada umumnya.
Hasil penelitian menunjukkan
bahwa penyusunan e-budgeting
dalam kegiatan anggaran
Pemerintah Kabupaten
Magelang telah membantu
efisiensi realisasi dana desa yaitu
dengan membuat proses
kegiatan anggaran menjadi lebih
biaya yang dikeluarkan oleh
Pemerintah Desa Balesari dalam
mencapai realisasi anggaran.
Sistem e-budgeting dan e-
reporting memungkinkan
pencarian dan perolehan
informasi terkait pencarian asal
anggaran dan implementasi
 dengan cepat.
4 Oletta E. Pengembangan Pengembangan sistem Aplikasi e-report layanan
Mambu, Yaulie Aplikasi E- dilakukan dengan RAD. masyarakat Kota Manado telah
D. Y Report Layanan berhasil dibangun dan dapat
Rindengan, dan Masyarakat untuk menjadi sarana informasi dalam
Stanley D. S Manado Smart mewujudkan pelayanan yang
Karouw City baik bagi masyarakat dalam
melaporkan suatu kejadian
darurat yang terjadi di
lingkungan Kota Manado.
Aplikasi ini juga dapat
membantu pemerintah menerima 3. Pengembangan
setiap laporan dan informasi dari
masyarakat agar masalah yang
dilaporkan dapat diterima lebih
cepat, efektif dan efisien
1. Pengembangan
selanjutnya adalah
menambah fitur fitur
komentar antara user dan
operator, fitur respon time
apabila pengaduan sudah
ditangani atau belum.
2. Aplikasi dapat
memperluas kategori
pengaduan kejadian.
platform lebih luas seperti
dapat berjalan di iOS,
mobile, windows phone
bahkan yang lainnya.
4. Aplikasi diharapkan
dapat terintegrasi dengan
seluruh instansi
pemerintahan terkait

44

5 Soriya Sushila A Study of Penelitian ini menggunakan Hasil penelitian:
dan Dhaigude Corporate Web- analisis konten untuk  Tidak mendukung
Amol Based Reporting mengukur tingkat pelaporan asumsi adanya relasi
in Hotel Industry berbasis web di industri positif antara indeks
perhotelan India. keuangan dengan
profitabilitas dari pemilik banyak indikator atau
saham.
 Adanya keterkaitan
pelaporan melalui
internet dengan indeks
keuangan.
 Tidak ada keterkaitan
penting antara gaya
presentasi dengan
keterbukaan informasi.
45
dengan data yang
dibutuhkan.
Lingkup untuk penelitian
lebih lanjut meliputi:
1. Meningkatkan prediksi
model dengan
menambahkan lebih
lebih banyak prediktor.
2. Mencari cara untuk
mengurangi variasi dalam
pengungkapan.
3. Studi perbandingan
pada industri yang
berorientasi pada layanan
dan produk lainnya.
4. Melakukan penelitian
untuk mendapatkan
pelaporan berbasis web
 standar.
6 Hudaifi, Aditya Analisis dan Penelitian ini menggunakan Hasil penelitian menunjukkan Saat ini, masih terjadi
Soleh, dan Pengembangan metode pengembangan SDLC bahwa solusi dapat mempercepat keterbatasan dimana
Yuvita D. A. Sistem Informasi untuk mengembangkan proses pengalokasian gudang, belum adanya support dari
Novitasari Pendukung sistem informasi yang sehingga proses pendistribusian pihak armada ekspedisi
Keputusan mengotomatiskan penentuan berjalan lebih optimal. dan dari PT AHM untuk
Alokasi Gudang keputusan pengalokasian pemanfaatan teknologi
Pada PT Wahana gudang di PT Wahana Internet of Things (IoT),
Makmur Sejati Makmur Sejati dengan yaitu pemasangan chip
metode pengolahan data khusus pada setiap armada
Analytical Hierarchy Process ekspedisi, untuk secara
(AHP). otomatis mendeteksi
armada dan mengetahui
alokasi gudang tujuan.

Berdasarkan beberapa penelitian terkait sistem informasi e-Reporting diatas, khususnya yang dilakukan oleh (Saputra, Herdiansyah, &
Udariansyah, 2019) dan (Mambu, Rindengan, D, & Karouw, 2016) dengan menggunakan metode SDLC adaptif dengan pendekatan Rapid
Application Development (RAD) terbukti menghasilkan sistem e-Reporting yang mampu membantu masyarakat Buay Madang dan Manado
dalam melaporkan kejadian darurat dan membantu pemerintah untuk menerima setiap laporan dan informasi dari masyarakat dengan lebih

46
cepat, efektif dan efisien. Oleh karena itu, kami hendak mengembangkan sistem informasi e-Reporting dengan menggunakan metode SDLC
adaptif dengan pendekatan prototyping dimana hasil yang diharapkan berupa sistem informasi e-Reporting Change Request Management.
Penelitian yang dilakukan oleh (Soleh, Hudaifi, & Novitasari D. A., 2019) mengenai pengembangan sistem informasi Pendukung
Keputusan Alokasi Gudang menggunakan metode pengolahan data Analytical Hierarchy Process (AHP) terbukti mempercepat proses
pengalokasian gudang sehingga proses pendistribusian berjalan lebih optimal. Berdasarkan penelitian ini, kami memilih metode Analytical
Hierarchy Process (AHP) sebagai metode pengolahan data untuk menyediakan informasi pendukung keputusan pada sistem e-Reporting
berupa informasi untuk mendukung penentuan prioritasi release CR sebagai pembeda antara penelitian kami dengan penelitian sebelumnya.

47
 2.4. Kerangka Pikir

Fenomena / Identifikasi Masalah

Departemen terkait belum memaksimalkan data CR yang ada.
Terdapat delay akuisisi informasi yang menyebabkan terhambatnya operasional sehingga dapat terjadi penurunan kepuasan pelanggan.

Penentuan Judul / Topik

Pengembangan Sistem Informasi E-Reporting Manajemen Change Request

Teori
Teori Umum
Teori Khusus

State of the art Tujuan / Manfaat

memperoleh informasi terkait kategorisasi release CR sehingga meningkatkan kemampuan ITOC dalam mendeteksi dan menanggulangi anomali untuk menjaga tingkat layanan dan meng
Bagi
anado pejabat
dalam terkait, diharapkan
melaporkan dengandan
kejadian darurat adanya sistempemerintah
membantu e-Reportinguntuk
ini dapat menyediakan
menerima informasi
setiap laporan danterkait Change
informasi dari Request untuk
masyarakat membantu
dengan pengambilan
lebih cepat, keputusan
efektif dan efisien.untuk strategi pe

Literature Review

Hasil
Metode Penelitian
Analis tidak perlu menganalisa severity setiap CR karena sudah dilakukan oleh sistem dan Tim ITOC mela
Dari sudut pandang tim, pengerjaan dilakukan dengan SDLC dengan pendekatan Prototyping

 User Analisis
Requirement
  Solusi = E-Reporting + AHP
 
Kesimpulan
Hasil penelitian menunjukkan bahwa solusi mampu mendukung pemrosesan mendukung pemrosesan dan akuisisi informasi dan

Validasi Desain
Deep Interview dan Testing dengan user pendekatan Prototyping. Sistem

Gambar 2.11 Kerangka Pikir

48