31
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.
32
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.
33
• 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
34 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 Metrics Before After
Kesepakatan jenis layanan yang akan diterapkan, biaya dan user yang diperbolehkan request. Persentasi kesalahan jenis kategori request OK OK Jumlah request for change OK OK Jumlah incident OK OK Jumlah emergency request NA OK Sosialisasi kepada user, mudah diakses dan digunakan. Kecepatan mengakses SRM NA OK Status request update NA OK Penelusuran proses request NA OK Email Notification (Outlook) NA OK Standard prosedur setiap request (include PR, PO, WO). prosedur setiap request (include PR, PO, WO). Persentasi RFC yang di reject NA OK Percentasi request yang menyebabkan incident OK OK Jumlah request pending karena vendor purchase OK OK Flow proses request OK OK Support Desk sebagai Single Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas NA OK
35 Point of Contact untuk proses request dan Sistem Request otomatis melalui Request Fullfilment dan System Procurement. Persentasi request reassigned OK OK Persentasi request yang diselesaikan oleh SPoC OK OK Sistem Request Interface yang mempermudahkan user dan terintegrasi dengan sistem lain seperti Incident dan Change. Kemudahan sistem dalam menangani permintaan NA OK Memahami bahasa yang digunakan NA OK Kemudahan penggunaan menu yang disajikan OK OK Kelengkapan menu disajikan NA OK Tampilan user interface NA OK Kelengkapan komponen data permintaan OK OK Kelengkapan informasi yang disajikan NA OK Menyediakan permintaan sesuai dengan user satisfication dan memberikan kepuasan pada user. Persentasi jumlah waktu untuk menyelesaikan request OK OK Jumlah request yang tidak di deliver sesuai waktu yang diharapkan OK OK Jumlah SLA yang sesuai target OK OK Jumlah SLA yang tidak sesuai target OK OK Peningkatan kinerja karyawan IT Rata‐rata waktu untuk menyelesaikan request OK OK Rata‐rata waktu untuk merespon request OK OK Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas OK OK
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.
36
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.
37
38
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.
39 • 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
40 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.
• Jumlah request dan jenis nya tidak dapat termonitor.
4.2.3 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 KPI Score
Kesepakatan jenis layanan yang akan diterapkan, biaya dan user yang diperbolehkan request. Persentasi kesalahan jenis kategori request 3 4 12 2.6667 Jumlah request for change 2 NA 0 Jumlah incident 2 2 4
41 Jumlah emergency request 3 NA 0 Sosialisasi kepada user, mudah diakses dan digunakan. Kecepatan mengakses SRM 2 NA 0 0 Status request update 3 NA 0 Penelusuran proses request 3 NA 0 Email Notification (Outlook) 2 NA 0 Standard prosedur setiap request (include PR, PO, WO). prosedur setiap request (include PR, PO, WO). Persentasi RFC yang di reject 2 NA 0 3 Percentasi request yang menyebabkan incident 3 NA 0 Jumlah request pending karena vendor purchase 3 5 15 Flow proses request 3 1 3 Support Desk sebagai Single Point of Contact untuk proses request dan Sistem Request otomatis melalui Request Fullfilment dan System Procurement. Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas 3 NA 0 3 Persentasi request reassigned 2 NA 0 Persentasi request yang diselesaikan oleh SPoC 3 1 3 Sistem Request Interface yang mempermudahkan user dan terintegrasi dengan sistem lain seperti Incident dan Change. Kemudahan sistem dalam menangani permintaan 2 NA 0 2.0 Memahami bahasa yang digunakan 2 NA 0 Kemudahan penggunaan menu yang disajikan 2 0 Kelengkapan menu disajikan 2 NA 0 Tampilan user interface 2 NA 0 Kelengkapan komponen data permintaan 2 2 4 Kelengkapan informasi yang disajikan 2 NA 0
42 Menyediakan permintaan sesuai dengan user satisfication dan memberikan kepuasan pada user. Persentasi jumlah waktu untuk menyelesaikan request 3 1 3 3 Jumlah request yang tidak di deliver sesuai waktu yang diharapkan 3 0 Jumlah SLA yang sesuai target 3 NA 0 Jumlah SLA yang tidak sesuai target 3 NA 0 Peningkatan kinerja karyawan IT Rata‐rata waktu untuk menyelesaikan request 3 1 3 3 Rata‐rata waktu untuk merespon request 3 1 3 Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas 3 NA 0
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 KPI
BWA IP Infrastructure 3 Enterprise Information
Support 4 Enterprice Resource Planning ERP Business Analyst 4
ISP Infrastructure 4 IT Security 2 Network Infrastructure 3 Resource Management 4 Support Desk 5 System Infrastructure 1 BSS Customer Management 4 BSS Service Assurance 4 BSS Operation 4 BSS Service Management 4 BSS System Planning and
43
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 lain-lain) 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).
44
· 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,
45
· 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
46
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.
47
• 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
48
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.
49 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.
50
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
51
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
52
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
53 4.3.2.2 Service Request System
Gambar 4.9 Service Request System 4.3.2.3 Workflow
54 4.3.2.4 User Interface
Gambar 4.10.1 User Interface
55
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
56
• 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.
• Efektif dan efisien.
4.3.4 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.
57 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 (Senin-Jumat, 8:00 am - 5:00 pm)
58 Department
Response Time(Hour) 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
59
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)
60 Department
Resolution Time(Hour) 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.
61
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
Kesepakatan jenis layanan yang akan diterapkan, biaya dan user yang diperbolehkan request. Persentasi kesalahan jenis kategori request 3 5 15 4.4 Jumlah request for change 2 3 6 Jumlah incident 2 4 8 Jumlah emergency request 3 5 15 Sosialisasi kepada user, mudah diakses dan digunakan. Kecepatan mengakses SRM 2 4 8 2.8 Status request update 3 3 9 Penelusuran proses request 3 1 3 Email Notification (Outlook) 2 4 8 Standard prosedur setiap request (include PR, PO, WO). prosedur setiap request (include PR, PO, WO). Persentasi RFC yang di reject 2 5 10 3.36 Percentasi request yang menyebabkan incident 3 4 12 Jumlah request pending karena vendor purchase 3 4 12 Flow proses request 3 1 3
62 Support Desk sebagai Single Point of Contact untuk proses request dan Sistem Request otomatis melalui Request Fullfilment dan System Procurement. Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas 3 3 9 3.5 Persentasi request reassigned 2 5 10 Persentasi request yang diselesaikan oleh SPoC 3 3 9 Sistem Request Interface yang mempermudahkan user dan terintegrasi dengan sistem lain seperti Incident dan Change. Kemudahan sistem dalam menangani permintaan 2 2 4 2.1 Memahami bahasa yang digunakan 2 1 2 Kemudahan penggunaan menu yang disajikan 2 3 6 Kelengkapan menu disajikan 2 2 4 Tampilan user interface 2 1 2 Kelengkapan komponen data permintaan 2 3 6 Kelengkapan informasi yang disajikan 2 3 6 Menyediakan permintaan sesuai dengan user satisfication dan memberikan kepuasan pada user. Persentasi jumlah waktu untuk menyelesaikan request 3 1 3 1.25 Jumlah request yang tidak di deliver sesuai waktu yang diharapkan 3 2 6 Jumlah SLA yang sesuai target 3 1 3 Jumlah SLA yang tidak sesuai target 3 1 3 Peningkatan kinerja karyawan IT Rata‐rata waktu untuk menyelesaikan request 3 1 3 1.67 Rata‐rata waktu untuk merespon request 3 1 3 Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas 3 3 9
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:
63 • 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
KPI CSF Criti cal Hig h Medi um Lo w Criti cal Hig h Medi um Lo w BWA IP Infrastructure 4 3 3 0 80 45 15 Enterprise Information 1 0 0 0 564 Support
Enterprice Resource
Planning 1 0 0 0 5
ERP Business Analyst 3 3 0 0 45 15
ISP Infrastructure 5 5 0 0 75 25 IT Security 5 5 3 3 125 100 45 15 Network Infrastructure 5 2 4 3 125 40 60 15 Resource Management 4 3 0 0 60 15 Support Desk 3 4 0 0 45 20 System Infrastructure 1 1 0 0 15 5 BSS Customer Management 1 1 0 0 15 5 BSS Service Assurance 5 5 0 0 75 25 BSS Operation 0 0 0 0 BSS Service Management 1 0 0 15 0 BSS System Planning and Design 1 1 1 0 20 15 5
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
65
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:
dengan ,
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
) ( ˆ 2 y V t y± α n s y V 2 ) ( ˆ = 1 ) ( 1 2 2 − − =
∑
= n y y s n i i66
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:
Berikut adalah hasil survey perbandingan sistem request managemet dengan sistem manual dan kepuasan mereka terhadap sistem yang baru
KEPUASAN KEP EN TI N G A N 3.50 3.25 3.00 2.75 2.50 4.15 4.10 4.05 4.00 3.95 3.90 2.860 3.9729 13 12 11 10 9 87 6 5 4 3 2 1 IPA
67
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
68
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.
69
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.
70
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.
Kepuasan SRM
Perbandingan
SR dan SRM
Lebih Buruk Biasa Saja Lebih 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%71
Tabel 4.14.1 Kepuasan SRM
Berikut adalah tabel hasil survey mengenai ideal dan kepuasan terhadap sistem yang baru Ideal Kepuasan Tidak Puas Kurang Puas Biasa Saja Puas Sangat 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.
72
73
4.5 Perbandingan
Sebelum
dan Sesudah penerapan SRM
• Service Request SystemGambar 4.18 Service Request System
• Proses Flow
Before
74
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 After
Target Response
time NA Define
Target Resolve time NA Define
• Request Priority Before After Request priority NA Critical High Medium Low
