BAB 4 ANALISIS DAN PEMBAHASAN
Dewasa ini, persaingan bisnis telah menjadi begitu ketat dan bisnis harus ditingkatkan terus menerus untuk memenuhi kebutuhan pelanggan dan tetap bertahan. Sejak IT area telah menjadi bagian penting untuk mendukung bisnis, TI telah menjadi begitu fleksibel dan dinamis dalam rangka untuk mencocokkan perubahan bisnis. Reaktif, berdiri sendiri helpdesks tidak lagi memadai. Untuk memenuhi permintaan bisnis untuk diandalkan
layanan berbasis teknologi,
organisasi IT memerlukan manajemen pelayanan terpadu proses yang melihat komponen teknologi sebagai bagian yang saling berhubungan. BMC Remedy IT Service Management (ITSM) merupakan pilihan perangkat lunak yang digunakan untuk segera mendirikan proses manajemen pelayanan yang efektif dan efisien. BMC Remedy IT Service Management menyatukan support desk, insiden, Problem, Change, aset siklus hidup, dan aplikasi service level manajemen, serta manajemen konfigurasi database (CMDB), dengan model data tunggal, alur kerja platform, dan user interface. PT Bakrie Telecom Tbk (BTEL) sebelumnya telah menerapkan BMC Remedy Support Desk dan BMC Remedy Service Level Management untuk membantu mereka mengelola informasi mereka teknologi lingkungan. Untuk memperbaiki proses yang ada, BTEL mengimplementasikan BMC Remendy Change Management dan BMC Remedy Service Request Management.
31
4.1
Metode Goal Question Metrics Dalam melakukan pengukuran menggunakan Metode GQM, maka yang
pertama kali harus diketahui yaitu tujuan perusahaan, tahap selanjutnya yaitu melakukan pertanyaan-pertanyaan berdasarkan dari tujuan tersebut. Selanjutnya melakukan pengukuran terhadap pertanyaan tersebut yang hasilnya berupa metrics.
Gambar 4.1 Diagram GQM
4.1.1 Goal Dalam penerapan Service Request Managemnet, PT Bakrie Telecom memilki beberapa tujuan yaitu: •
Workflow bisnis proses menjadi sesuai dengan standard.
•
Tracking process dapat dilakukan.
•
Request dapat berjalan sesuai dengan SLA yang telah disepakati.
•
Dokumentasi lengkap dan jelas.
32
•
Dapat melayani request pelanggan sesuai dengan customer satisfication (cepat dan tepat).
•
Mengurangi cost.
4.1.2 Question Pada kuesioner yang disebar, diberikan beberapa pertanyaan langsung dan kolom yag harus diisi. Pada kolom tersebut diminta untuk mengisi tingkat kepentingan dan kepuasan menurut user terhadap beberapa pertanyaan. Hasil dari kuesioner ini dibutuhkan untuk menentukan item yang menjadi metriks. Berikut item yang terdapat pada kuesioner: 1. Identifikasi user 2. User Interface 3. Flow Process 4. Service Level Agreement 5. Perbandingan dengan sistem yang lama 4.1.3 Metrics Dari pertanyaan pada kuesioner, maka kami mendapatkan beberapa metriks yang akan kami lakukakan perhitungannya. 1. Kecepatan untuk mengakses SRM Remedy 2. Kemudahan sistem dalam menagani request 3. Pemahaman bahasa yang digunakan 4. Kemudahan dalam peggunaan menu yang disajikan 5. Kelengkapan menu yang disajikan 6. Tampilan user interface 33
7. Kelengkapan data komponen request 8. Kelengkapan informasi yang disajikan 9. Flow Process Request 10. Status request update 11. Target waktu untuk menangani request (SLA) 12. Email notification 13. Tracking Process 14. Response dan Resolve Time 15. Jumlah request sesuai prioritas dan pencapaian target 16. Jumlah request yang tidak sesuai kategori 4.1.4 Checklist Metriks sebelum dan sesudah menerapkan Service Request berdasarkan ITIL CSF Kesepakatan jenis layanan yang akan diterapkan, biaya dan user yang diperbolehkan request.
Metrics Persentasi kesalahan jenis kategori request Jumlah request for change Jumlah incident
Jumlah emergency request Kecepatan mengakses SRM Sosialisasi kepada Status request update user, mudah Penelusuran proses request diakses dan digunakan. Email Notification (Outlook) Standard prosedur Persentasi RFC yang di reject setiap request Percentasi request yang menyebabkan incident (include PR, PO, Jumlah request pending karena vendor purchase WO). prosedur setiap request (include PR, PO, WO). Flow proses request Support Desk Persentasi request yang diselesaikan sesuai dengan sebagai Single target time sesuai prioritas
34
Before OK OK OK
After OK OK OK
NA NA NA NA NA NA OK OK
OK OK OK OK OK OK OK OK
OK
OK
NA
OK
Point of Contact untuk proses request dan Sistem Request otomatis melalui Request Fullfilment dan System Procurement. Sistem Request Interface yang mempermudahkan user dan terintegrasi dengan sistem lain seperti Incident dan Change. Menyediakan permintaan sesuai dengan user satisfication dan memberikan kepuasan pada user. Peningkatan kinerja karyawan IT
Persentasi request reassigned
OK
OK
Persentasi request yang diselesaikan oleh SPoC Kemudahan sistem dalam menangani permintaan Memahami bahasa yang digunakan Kemudahan penggunaan menu yang disajikan Kelengkapan menu disajikan Tampilan user interface Kelengkapan komponen data permintaan
OK NA NA OK NA NA OK
OK OK OK OK OK OK OK
Kelengkapan informasi yang disajikan Persentasi jumlah waktu untuk menyelesaikan request Jumlah request yang tidak di deliver sesuai waktu yang diharapkan Jumlah SLA yang sesuai target
NA
OK
OK
OK
OK OK
OK OK
OK OK OK
OK OK OK
OK
OK
Jumlah SLA yang tidak sesuai target Rata‐rata waktu untuk menyelesaikan request Rata‐rata waktu untuk merespon request Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas
Tabel 4.1 Checklist Metriks 4.2 Sistem Request Sistem permintaan yang digunakan yaitu menggunakan form. Dan approvalnya pun dijalankan dengan mengedarkan form tersebut. Masing-masing request menggunakan form yang berbeda-beda, kebutuhan approvalnya pun berbeda beda.
4.2.1
Proses Flow
35
Gambar 4.2 Proses Flow
•
Request Form Form yang digunakan pada sistem ini berbeda-beda. Form tersebut dapat diambil oleh para user di web BtelPortal untuk masing masing request yang selanjutnya di print untuk dilengkapi. Berikut contoh form yang digunakan untuk request:
36
Gambar 4.3 Access Request Form
37
Gambar 4.4 Client Request Form
•
Approval Kebutuhan approval pada sistem request ini berbeda-beda disesuaikan dengan kebijakan masing-masing support grup dalam mendefinisikan kebutuhan approval. Pada request IT Client Request membutuhkan approval sampai 3 level diatas. Sedangkan pada request access hanya membutuhkan approval satu level. Jika di reject maka proses request berakhir, sedangkan jika di approve akan dilanjutkan prosesnya.
38
•
Request Fulfillment Setelah proses approval selesai, form diserahkan langsung ke support grup yang terkait termasuk user yang berada di luar HO. Hal ini lah yang membuat banyaknya request yang miss dikarenakan kesalahan pengiriman ke support grup yang terkait atau dokumen yang tidak sampai. Setelah form tersebut sampai di support grup terkait, dilanjutkan approval di IT Support Grup tersebut. Jika di request tersebut di approve maka proses akan dilanjutkan. Sedangkan jika di reject maka request tidak akan dilanjutkan. Dalam proses nya setelah siap makan user akan diinfokan melalui email untuk proses deployment request tersebut. Support Untuk Support Grup yang mendata request yang masuk, mereka mencatat semua request menggunakan excel.
4.2.2
Request Priority
Pada sistem ini priority dilakukan sesuai dengan user level. Maka para support grup akan memperhatikan user level dan memprioritaskan request dari user dengan level gm, VP, EVP dan BOD.
4.2.3 Kelebihan Sistem Request •
Approval menjadi lebih ketat dan terpantau karena menggunakan form.
39
4.2.4 Kelemahan Sistem Request •
SLA tidak dapat dipenuhi dan sulit untuk dimonitor. Hal ini dikarenakan sejak awal permintaan approval bisa memakan waktu yang sangat lama.
•
Data hilang. Form yang digunakan sering hilang.
•
Penelusuran Proses menjadi sulit. Jika request lama, sulit untuk mengetahui apa yang menyebabkan dan dimana bottle necknya.
•
Tidak Efisien dan Tidak Go Green.
•
User tidak mengetahui update dari permintaannya. Hal ini dikarenakan user tidak tahu kemana harus bertanya dan dimana posisi requestnya saat ini.
•
4.2.3
Jumlah request dan jenis nya tidak dapat termonitor.
Pengukuran Sistem Request
4.2.3.1 Pengukuran Proses Berikut adalah penilaian proses menggunakan Metrics, KPI dan CSF Sistem Request Critical Success Factors
Metrics
W
Persentasi kesalahan jenis kategori request Kesepakatan jenis Jumlah request for change layanan yang akan diterapkan, biaya dan user yang diperbolehkan request. Jumlah incident
40
KPI
3
Score
4 12
2 NA
0
2
4 2.6667
2
Sosialisasi kepada user, mudah diakses dan digunakan. Standard prosedur setiap request (include PR, PO, WO). prosedur setiap request (include PR, PO, WO). Support Desk sebagai Single Point of Contact untuk proses request dan Sistem Request otomatis melalui Request Fullfilment dan System Procurement.
Sistem Request Interface yang mempermudahkan user dan terintegrasi dengan sistem lain seperti Incident dan Change.
Jumlah emergency request
3 NA
0
Kecepatan mengakses SRM Status request update Penelusuran proses request Email Notification (Outlook)
2 3 3 2
0 0 0 0
Persentasi RFC yang di reject Percentasi request yang menyebabkan incident Jumlah request pending karena vendor purchase
2 NA 0 3 NA 0 3 5 15
Flow proses request
3
1
3
Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas
3 NA
0
Persentasi request reassigned
2 NA
0
Persentasi request yang diselesaikan oleh SPoC
3
1
3
3
Kemudahan sistem dalam menangani permintaan Memahami bahasa yang digunakan Kemudahan penggunaan menu yang disajikan Kelengkapan menu disajikan Tampilan user interface Kelengkapan komponen data permintaan Kelengkapan informasi yang disajikan
2 2 2 2 2 2 2
NA NA
0 0 0 0 0 4 0
2.0
41
NA NA NA NA
NA NA 2 NA
0
3
Menyediakan permintaan sesuai dengan user satisfication dan memberikan kepuasan pada user. Peningkatan kinerja karyawan IT
Persentasi jumlah waktu untuk menyelesaikan request Jumlah request yang tidak di deliver sesuai waktu yang diharapkan Jumlah SLA yang sesuai target
3
Jumlah SLA yang tidak sesuai target Rata‐rata waktu untuk menyelesaikan request Rata‐rata waktu untuk merespon request Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas
1
3
3 3 NA
0 0
3 NA 3 1 3 1
0 3 3
3
3 NA
0
3
Tabel 4.2 Pengukuran Sistem Request
4.2.3.2 Pengukuran kinerja Pegawai IT Berikut adalah penilaian kinerja pegawai dari masing-masing departement menggunakan KPI
Departement BWA IP Infrastructure Enterprise Information Support Enterprice Resource Planning ERP Business Analyst ISP Infrastructure IT Security Network Infrastructure Resource Management Support Desk System Infrastructure BSS Customer Management BSS Service Assurance BSS Operation BSS Service Management BSS System Planning and Design
KPI 3 4 4 4 2 3 4 5 1 4 4 4 4 4
42
Tabel 4.3 KPI Sistem Request
4.3
Service Request Management berdasarkan ITIL
Istilah ‘Service Request (Permintaan Layanan)’ digunakan sebagai uraian umum untuk banyak jenis permintaan yang bervariasi yang terjadi di Department TI oleh pengguna. Permintaan layanan ini memiliki sifat resiko rendah, sering terjadi, berbiaya rendah (sebagai contoh suatu permintaan untuk mengubah password, suatu permintaan untuk menginstal aplikasi perangkat lunak tambahan, dan lainlain) atau hanya sekedar permintaan informasi tetapi dalam skala sering . Dengan SRM, end user mendapatkan kemampuan untuk menolong dirinya sendiri, sehingga akan mengurangi banjir permintaan ke service desk. Ini mendorong IT untuk lebih fokus ke aktivitas yang lebih kritikal, seperti memecahkan masalah yang berhubungan dengan kegagalan layanan atau merestorasi layanan kritikal Tujuan-tujuan proses pemenuhan permintaan meliputi: ·
Untuk menyediakan saluran komunikasi dengan para pemakai yang meminta dan menerima layanan standar.
·
Untuk menyediakan informasi kepada para pemakai dan customer tentang ketersediaan layanan serta prosedur untuk memperoleh layanan tersebut.
·
Sebagai sumber dan untuk memberikan komponen layanan standar yang diminta (sebagai contoh lisensi dan media perangkat lunak).
43
·
Untuk membantu dengan informasi umum, mengenai keluhan atau komentar tentang ketersediaan layanan.
Service Request Management adalah menyediakan akses cepat dan efektif untuk men-standar-kan layanan agar user bisa menggunakannya untuk meningkatkan produktivitas atau kualitas bisnis serta produk layanan. Service Request Management secara efektif mengurangi keterlibatan birokrasi dalam meminta dan menerima akses layanan yang sudah ada atau baru, dengan begitu juga akan mengurangi biaya penyediaan layanan. Informasi yang dibutuhkan untuk setiap request mencakup: ·
Nomor referensi yang unik
·
Pengkategorian dari request
·
Request urgency (tinggi, rendah, sedang dan penting)
·
Impact request (impact business, departemen, group atau user)
·
Prioritas request
·
Tanggal dan waktu pencatatan request
·
Nama atau identitas orang yang request
·
Metode pemberitahuan (melalui telephone, automatic, e-mail, dari orang secara langsung, dan sebagainya)
·
Metode jawaban (telephone, mail, etc.)
·
Deskripsi dan rational
·
Status request (draft, planning in progress, schedule for approval, closed, etc.)
44
·
Support group/person yang menangani request
·
Berelasi dengan problem (masalah) / known error (diketahui ada kesalahan)
·
Aktivitas-aktivitas untuk menangani request
·
Tanggal dan waktu resolusi
·
Kategori closure
·
Jam dan waktu closure.
4.3.1
Design Service Request Management
4.3.1.1 Business Requirements
Gambar 4.5 Business Requirements
45
4.3.1.2 Process Flow Sistem Request Management berdasarkan ITIL
Gambar 4.6 Process Flow SRM Berikut adalah details aktifitas pada Service Request Management: •
User login pada remedy web, menggunakan username dan password sesuai dengan login mereka ke active directory.
•
Remedy akan menampilkan pilihan Service Request yang didalamnya terdiri dari dua kategori yaitu request dan incident.
•
Setelah user memilih request/issue, user diharuskan mengisi informasi yang diperlukan lalu di submit dan sistem akan melanjutkan ke proses approval.
46
•
Approver akan mendapatkan email notification untuk setiap request yang mambutuhkan approval mereka.
•
Setelah proses approval selesai, tiket tersebut akan dialjutkan ke support grup yang terkait dan menginfokan dengan memberikan email notification.
•
User dan Support grup dapat berkomunikasi menggunakan workinfo.
4.3.1.3 User Role
Tabel 4.4 User Role 4.3.1.4 Service Request Status Diagram
47
Gambar 4.7 Service Request Status Diagram
Tabel 4.5 Service Request Status Diagram
4.3.1.5 Request Priority Pada System Request Management berdasarkan ITIL membagi priority menjadi 4 prioritas yaitu Critical, High, Medium dan Low. Setiap user saat membuat tiket bisa memilih priority nya disesuaikan dengan kebutuhannya.
48
4.3.1.6 Time Schedule
Gambar 4.7 Time Schedule
4.3.1.7 Email Notification Matrix and Templates Pada System Request Management yang diterapkan menggunakan remedy, terdapat email notification. Email notification tersebut digunakan untuk mengupdate kepada user semua proses yang terjadi, selain itu juga untuk mengingatkan pada approver jika statusnya masih menunggu approve mereka.
49
Support Grup yang di assign pun akan menerima email notification saat tiket tersebut fully approve dan di assign ke departemen yang bersangkutan.
Tabel 4.6.1 Email Notification Matrix and Templates
Tabel 4.6.2 Email Notification Matrix and Templates
50
4.3.1.8 Outlook Form User Interface Design Outlook Form digunakan untuk mempermudah user dalam pembuatan tiket. Microsoft Outlook digunakan sehari-hari oleh user, sehingga user tidak perlu kesulitan membuat tiket
Gambar 4.8 Outlook Form User Interface Design
4.3.1.9 Milestone
Tabel 4.7.1 Milestone
51
Tabel 4.7.2 Milestone
4.3.2
Deployment Service Request Mangement
4.3.2.1 Jenis Request Standard Request 1. Update Payment Request 2. Request for Network Access 3. Request form Network Connectivity 4. IT Client and Server Request
52
4.3.2.2 Service Request System
Gambar 4.9 Service Request System 4.3.2.3 Workflow
Gambar 4.10 Workflow 53
4.3.2.4 User Interface
Gambar 4.10.1 User Interface
Gambar 4.10.2 User Interface
54
Gambar 4.10.3 User Interface
Gambar 4.10.4 User Interface
4.3.3
Kelebihan Sistem Request Management berdasarkan ITIL
Berikut adalah kelebihan yang didapatkan setelah penerapan System Request Management: •
Terdapat standard proses request
•
Dapat menerapkan Service Level Agreement pada masing-masing request. 55
•
Update proses kepada user maupun support grup terkait.
•
User dapat mengetahui status request.
•
Data setiap request tersimpan dengan rapih pada database sistem.
•
Proses request menjadi lebih cepat. Karena user, approver dan support grup akan mendapatkan reminder dan update melalui email.
•
4.3.4
Efektif dan efisien.
Kekurangan System Request Management berdasarkan ITIL
Terdapat beberapa kelemahan terhadap System Request Management berdasarkan ITIL yang telah diterapkan di Bakrie Telecom: •
Approver menjadi tidak teliti saat memberikan approval, mereka cenderung select all dan approve untuk semua request tanpa membuka satu persatu.
•
Sistem yang tidak user friendly.
•
Tidak ada integrasi dengan bagian di luar IT seperti Procurement yang terkait dalam proses request, sehingga tiket terpending di support grup dengan keterangan vendor purchase.
4.3.5
Service Level Agreement
Sebuah perjanjian tingkat layanan (sering disingkat SLA) adalah bagian dari kontrak layanan dimana tingkat pelayanan yang ditetapkan secara formal. Dalam praktek, istilah SLA kadang-kadang digunakan untuk merujuk pada waktu pengiriman dikontrak (layanan) atau kinerja.
56
4.3.5.1 Customer Response Time Targets Respon Time adalah waktu yang diperlukan untuk menyelesaikan request user dengan cara yang non-otomatis. Hal ini diukur dari waktu catatan Peristiwa dibuat, baik oleh user melalui penyampaian web Helpdesk atau oleh IT Service Desk atau kelompok pendukung lainnya secara manual membuat catatan, sampai request mereka telah diterima dan sedang ditangani. Pelanggan harus dihubungi baik melalui telepon atau email dan Request ditandai "In Progress". Secara khusus, Respon Waktu adalah diukur dari waktu dari penciptaan Request sampai "In Progress" memperbarui status, diukur selama jam kerja Stanford (SeninJumat, 8:00 am - 5:00 pm)
Tabel 4.8 Response Time Targets
57
Response Time(Hour) Department
Critical High
Medium Low
BWA IP Infrastructure
-
221.39 167.54
198.39
Enterprise Information Support
-
-
-
36.00
Enterprice Resource Planning
-
-
-
-
ERP Business Analyst
-
-
4.06
3.66
ISP Infrastructure
-
-
0.68
-
IT Security
865.82
382.96 416.64
350.77
Network Infrastructure
0.25
69.65
159.80
144.29
Resource Management
-
-
16.48
0.29
Support Desk
-
-
6.54
6.35
System Infrastructure
-
5.97
-
10.79
BSS Customer Management
-
-
-
7.89
BSS Service Assurance
-
-
56.51
3.05
BSS Operation
-
-
-
-
BSS Service Management
-
-
-
-
BSS System Planning and Design
-
-
17.35
18.19
Tabel 4.9 Department Response Time
Tabel di atas adalah merupakan pencapaian response time masing-masing departemen IT periode Januari - April 2011. Pada periode tersebut hasil rata-rata
58
response time yang berwarna merah menandai bahwa sudah melewati target response time.
4.3.5.2 Customer Resolution Time Targets Resolusi Waktu adalah waktu yang diperlukan untuk menyelesaikan request dari user atau menjawab pertanyaan mereka. Hal ini diukur dari waktu catatan Request dibuat, baik oleh pelanggan melalui penyampaian web Helpdesk atau oleh IT Service Desk atau kelompok pendukung lainnya secara manual membuat catatan, hingga waktu yang pelanggan disarankan masalah mereka telah diselesaikan. Secara khusus, Respon Waktu adalah waktu dari penciptaan Insiden sampai update status "Terselesaikan", diukur selama jam kerja Stanford (Senin-Jumat, 8:00 am - 5:00 pm)
Tabel 4.10 Resolution Time Targets
59
Resolution Time(Hour) Department
Critical
High
Medium
Low
BWA IP Infrastructure
-
2104.97
1644.19
1446.62
Enterprise Information Support
-
-
-
165.22
Enterprice Resource Planning
-
-
-
-
ERP Business Analyst
-
-
309.88
294.94
ISP Infrastructure
-
-
-
-
IT Security
3311.01
1861.16
2154.65
1738.61
Network Infrastructure
4176.53
287.13
1433.73
1262.62
Resource Management
-
-
349.29
298.99
Support Desk
-
-
127.69
138.12
System Infrastructure
-
3170.68
-
1252.22
BSS Customer Management
-
-
-
675.44
BSS Service Assurance
-
-
1084.30
410.06
BSS Operation
-
-
-
-
BSS Service Management
-
-
-
-
BSS System Planning and Design
-
-
622.81
657.08
Tabel 4.11 Department Resolution Time Targets
Pada tabel tersebut merupakan rata-rata waktu yang dibutuhkan departemen untuk menyelesaikan tiket. Dari data tersebut, semua departemen melewati target resolution time.
60
4.3.6 Pengukuran Sistem Request Management berdasarkan ITIL 4.3.6.1 Pengukuran Proses Berikut adalah penilaian proses menggunakan Metrics, KPI dan CSF Sistem Request Management berdasarkan ITIL V3 yang dilakukan Jan- April 2011
Critical Success Factors
Metrics
W
KPI
Score
Persentasi kesalahan jenis kategori request
3
5 15
Jumlah request for change
2
3
6
Kesepakatan jenis Jumlah incident layanan yang akan diterapkan, biaya dan user yang diperbolehkan request. Jumlah emergency request
2
4
8
3
5 15
4.4
Kecepatan mengakses SRM Status request update Penelusuran proses request Email Notification (Outlook)
2 3 3 2
4 3 1 4
2.8
Persentasi RFC yang di reject Percentasi request yang menyebabkan incident Jumlah request pending karena vendor purchase
2 3 3
5 10 4 12 4 12
Flow proses request
3
1
Sosialisasi kepada user, mudah diakses dan digunakan. Standard prosedur setiap request (include PR, PO, WO). prosedur setiap request (include PR, PO, WO).
61
8 9 3 8
3
3.36
Support Desk sebagai Single Point of Contact untuk proses request dan Sistem Request otomatis melalui Request Fullfilment dan System Procurement.
Sistem Request Interface yang mempermudahkan user dan terintegrasi dengan sistem lain seperti Incident dan Change. Menyediakan permintaan sesuai dengan user satisfication dan memberikan kepuasan pada user. Peningkatan kinerja karyawan IT
Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas
3
3
Persentasi request reassigned
2
5 10
Persentasi request yang diselesaikan oleh SPoC
3
3
9
3.5
Kemudahan sistem dalam menangani permintaan Memahami bahasa yang digunakan Kemudahan penggunaan menu yang disajikan Kelengkapan menu disajikan Tampilan user interface Kelengkapan komponen data permintaan Kelengkapan informasi yang disajikan
2 2 2 2 2 2 2
2 1 3 2 1 3 3
4 2 6 4 2 6 6
2.1
Persentasi jumlah waktu untuk menyelesaikan request Jumlah request yang tidak di deliver sesuai waktu yang diharapkan Jumlah SLA yang sesuai target
3
1
3
3 3
2 1
6 3
Jumlah SLA yang tidak sesuai target Rata‐rata waktu untuk menyelesaikan request Rata‐rata waktu untuk merespon request Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas
3 3 3
1 1 1
3 3 3
1.25
3
3
9
1.67
Tabel 4.12 Hasil Pengukuran CSF Selang score untuk KPI dan CSF adalah 1-5, dimana makin besar score maka makin baik performancenya. Berikut adalah penilaian untuk dari Actual Operational ke nilai KPI: •
1 : 0-20%
62
9
•
2 : 21-40%
•
3 : 41-60%
•
4 : 61-80%
•
5 : 81-100%
Namun untuk metrik-metrik yang ditandai dengan huruf tebal, penilaian Actual Operational ke nilai KPI adalah sebagai berikut: •
1 : 81-100%
•
2 : 61-80%
•
3 : 41-60%
•
4 : 21-40%
•
5 : 0-20%
Dari hasil pengukuran diatas, terdapat beberapa criteria success facor yag mendapatkan score dibawah 3. Hal ini membuktikan bahwa perlu ada improvement dari masing-masing metrics. Sehingga bisa meningkatkan performance dan mencapai CSF.
4.3.6.2 Pengukuran kinerja Pegawai IT Berikut adalah penilaian kinerja pegawai dari masing-masing departement menggunakan KPI setelah menerapakan ITIL V3
Department BWA IP Infrastructure Enterprise Information
Criti cal
KPI CSF Hig Medi Lo Criti Hig Medi Lo h um w cal h um w 4 3 3 0 80 45 15 1 0 0 0 5
63
Support Enterprice Resource Planning ERP Business Analyst ISP Infrastructure IT Security Network Infrastructure Resource Management Support Desk System Infrastructure BSS Customer Management BSS Service Assurance BSS Operation BSS Service Management BSS System Planning and Design
1 3 5 3
0 0 0 0 0 0 125 100
0 45 75 45
5 15 25 15
5
5
3 5 3
5
2
4
3
125
40
60
15
4 3 1
3 4 1
0 0 0
0 0 0
60 45 15
15 20 5
1
1
0
0
15
5
5
5
0 0
0 0
75 0
25 0
0
0
15
0
0
20
15
5
1 1
1
1
Tabel 4.13 Department KPI
Dari hasil tersebut dapat terlihat improvement setelah penerapan SRM ITIL V3, yaitu dengan adanya perbaikan pada KPI pegawai dibandingkan sebelum menggunakan ITIL V3.
4.4
Survey
Survey merupakan metode untuk mengumpulkan data primer yang mendasarkan pada komunikasi dengan perwakilan sampel secara individu. Jenis penarikan contoh yang dilakukan adalah Sistem Random Sampling
64
Pada penelitian ini survey dilakukan sebelum dan sesudah penerapan itil berdasarkan ITIL. Jumlah populasi (pegawai bakrie Telecom) adalah 1240, pada survey pertama jumlah sampling yang didapatkan sebesar 447 sedangkan pada survey kedua jumlah sampling sebesar 638. Rumus menghitung selang kepercayaan: y ± tα
Vˆ ( y )
dengan
s2 Vˆ ( y ) = n
2
n
, s2 =
∑(y i =1
− y)2
n −1
Maka didapatkan nilai selang kepercayaan untuk survey pertama sebesar 7% sedangkan untuk survey kedua sebesar 10%. Dari hasil survey kedua, jumlah pengguna ITIL sebesar 96,72% dari total pegawai. Hal ini berarti Sistem tersebut sudah di sosialisasikan untuk digunakan oleh semua pegawai Bakrie Telecom.
Gambar 4.11 Diagram Pengguna ITIL PT Bakrie Telecom mengimplementasikan Service Request Management, Incident Management, Problem Management, Knowledge Management dan
65
i
Release
Management
menggunakan
Remedy.
Dari
sistem
yang
telah
diimplementasikan, berikut adalah persentasi sistem yang sering digunakan oleh user.
Gambar 4.12 Diagram Pengguna Sistem
Dari hasil survey yang dilakukan, didapatkan hasil IPA sebagai respon terhadap penerapan Service Request Management sebagai berikut:
IPA 4.15
2.860
4
KEPENTINGAN
4.10
4.05
2 5
12
4.00
1
3.9729
6 13
10
Berikut 3.95adalah hasil survey perbandingan sistem request managemet dengan 3
9
7 8
11
sistem manual dan kepuasan mereka terhadap sistem yang baru 3.90
2.50
2.75
3.00 KEPUASAN
66
3.25
3.50
Gambar 4.13 Hasil IPA Legend: Pertanyaan 1
Kecepatan untuk mengakses SRM Remedy
2
Kemudahan sistem dalam menangani request
3
Pemahaman bahasa yang digunakan
4
Target waktu untuk menangani request (SLA)
5
Kelengkapan menu yang disajikan
6
Tampilan user interface
7
Kelengkapan data komponen request
8
Kelengkapan informasi yang disajikan
9
Flow proses request
10
Status request update
11
Kemudahan dalam penggunaan menu yang disajikan
12
Email notification (Outlook)
13
Tracking proses
Dari hasil IPA tersebut terlihan pada kuadran [1] yang merupakan prioritas utama dengan kepentingan tinggi namun hasil kepuasananya rendah maka harus ditingkatkan yaitu point pertanyaan (4), (2), dan (5). Untuk kuadran [2] yang terdiri dari pertanyaan (1) dan (12) harus dipertahankan pencapaiannya. Pada kuadran [3] merupakan bagian dengan prioritas rendah yaitu pertanyaan (3), (6), (9) dan (13). Sedangkan pada kuardan [4] merupakan daerah yang berlebih yaitu
67
kepentingannya rendah namun dengan kepuasan tinggi terdiri dari pertanyaan (8), (10), dan (11)
Berikut adalah hasil survey perbandingan Sistem Request Managemet dengan sistem manual dan kepuasan mereka terhadap sistem yang baru
Gambar 4.14 Hasil Penilaian SRM
Dari grafik diatas 60% menganggap bahwa sistem yang ada saat ini sudah ideal dan sisanya menilai belum ideal.
68
Gambar 4.15 Hasil Penilaian Kepuasan User
Dari hasil tersebut dapat dilihat bahwa 38% user menilai puas dan 50% menilai biasa saja. Sedangkan 8% menilai kurang pua dan 4% menilai tidak puas. Maka dapat disimpulkan bahwa user puas terhadap sistem request baru yang telah diterapkan.
69
Gambar 4.16 Pendapat User Sebelum dan Sesudah SRM Dari diagram di atas dapat dilihat bahwa jika dibandingkan dengan sistem yang lama, user menilai sistem yang baru lebih baik.
Perbandingan SR dan SRM
Kepuasan SRM Lebih
Biasa
Lebih
Buruk Saja
Baik
Tidak Puas
0%
4%
0%
Kurang Puas
2%
2%
4%
Biasa Saja
0%
34%
16%
Puas
0%
2%
36%
Sangat Puas
0%
0%
0%
70
Tabel 4.14.1 Kepuasan SRM
Berikut adalah tabel hasil survey mengenai ideal dan kepuasan terhadap sistem yang baru
Kepuasan Ideal
Tidak
Kurang
Biasa
Sangat
Puas
Puas
Saja
Puas Puas
Tidak
4%
6%
38%
12%
0%
Ya
0%
2%
12%
26%
0%
Tabel 4.14.2 Kepuasan SRM
Berikut adalah hasil perbandingan dari hasil survey sebelum dan sesudah penerapan Service Request Management berdasarkan ITIL yang menilai kepuasan user tehadap kinerja pegawai IT dan response permintaan user.
71
Gambar 4.17 Hasil Survei Kepuasan User
72
4.5 •
Perbandingan Sebelum dan Sesudah penerapan SRM Service Request System
Gambar 4.18 Service Request System
•
Proses Flow Before
After
73
Setelah menerapkan Service Request Management berdasarkan ITIL terdapat proses dengan status yang jelas. Sehingga memudahkan dalam tracking process. Informasi perubahan status akan diinformasikan melalui email kepada user dan support grup terkait. Semua proses request menggunakan proses flow yang sama, begitupula dengan approval yang dibutuhkan. •
SLA Before Target Response time Target Resolve time
•
NA NA
After Define Define
Request Priority Before
Request priority
NA
74
After Critical High Medium Low
