BAB 4 ANALISIS DAN PEMBAHASAN

Transkripsi

1 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

2 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 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

3 Dapat melayani request pelanggan sesuai dengan customer satisfication (cepat dan tepat). Mengurangi cost 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 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

4 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. notification 13. Tracking Process 14. Response dan Resolve Time 15. Jumlah request sesuai prioritas dan pencapaian target 16. Jumlah request yang tidak sesuai kategori Checklist Metriks sebelum dan sesudah menerapkan Service Request berdasarkan ITIL CSF Metrics Before After Kesepakatan jenis Persentasi kesalahan jenis kategori request OK OK layanan yang akan Jumlah request for change OK OK diterapkan, biaya Jumlah incident OK OK dan user yang diperbolehkan request. Jumlah emergency request NA OK 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 Kecepatan mengakses SRM NA OK Status request update NA OK Penelusuran proses request NA OK Notification (Outlook) NA OK 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 Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas NA OK 34

5 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 OK OK 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 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 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 Proses Flow 35

6 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

7 Gambar 4.3 Access Request Form 37

8 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

9 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 untuk proses deployment request tersebut. Support Untuk Support Grup yang mendata request yang masuk, mereka mencatat semua request menggunakan excel 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 Kelebihan Sistem Request Approval menjadi lebih ketat dan terpantau karena menggunakan form. 39

10 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 Pengukuran Sistem Request 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 Jumlah request for change 2 NA 0 Jumlah incident

11 Jumlah emergency request 3 NA 0 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. Kecepatan mengakses SRM 2 NA 0 Status request update 3 NA 0 Penelusuran proses request 3 NA 0 Notification (Outlook) 2 NA 0 Persentasi RFC yang di reject 2 NA 0 Percentasi request yang menyebabkan incident 3 NA 0 Jumlah request pending karena vendor purchase Flow proses request 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 Sistem Request Interface yang mempermudahkan user dan terintegrasi dengan sistem lain seperti Incident dan Change. Kemudahan sistem dalam menangani permintaan 2 NA 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 Kelengkapan informasi yang disajikan 2 NA

12 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 3 0 Jumlah SLA yang sesuai target 3 NA 0 Jumlah SLA yang tidak sesuai target 3 NA 0 Rata rata waktu untuk menyelesaikan request Rata rata waktu untuk merespon request Persentasi request yang diselesaikan sesuai dengan target time sesuai prioritas 3 NA Tabel 4.2 Pengukuran Sistem Request 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 Design 4 42

13 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

14 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, , 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

15 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 Design Service Request Management Business Requirements Gambar 4.5 Business Requirements 45

16 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

17 Approver akan mendapatkan 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 notification. User dan Support grup dapat berkomunikasi menggunakan workinfo User Role Service Request Status Diagram Tabel 4.4 User Role 47

18 Gambar 4.7 Service Request Status Diagram Tabel 4.5 Service Request Status Diagram 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

19 Time Schedule Gambar 4.7 Time Schedule Notification Matrix and Templates Pada System Request Management yang diterapkan menggunakan remedy, terdapat notification. 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

20 Support Grup yang di assign pun akan menerima notification saat tiket tersebut fully approve dan di assign ke departemen yang bersangkutan. Tabel Notification Matrix and Templates Tabel Notification Matrix and Templates 50

21 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 Milestone Tabel Milestone 51

22 Tabel Milestone Deployment Service Request Mangement 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

23 Service Request System Workflow Gambar 4.9 Service Request System Gambar 4.10 Workflow 53

24 User Interface Gambar User Interface Gambar User Interface 54

25 Gambar User Interface Gambar User Interface 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

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

27 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 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) Tabel 4.8 Response Time Targets 57

28 Response Time(Hour) Department Critical High Medium Low 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 Tabel 4.9 Department Response Time Tabel di atas adalah merupakan pencapaian response time masing-masing departemen IT periode Januari - April Pada periode tersebut hasil rata-rata 58

29 response time yang berwarna merah menandai bahwa sudah melewati target response time 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

30 Resolution Time(Hour) Department Critical High Medium Low 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 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

31 4.3.6 Pengukuran Sistem Request Management berdasarkan ITIL 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 Jumlah request for change Kesepakatan jenis layanan yang akan diterapkan, biaya dan user yang diperbolehkan request. Jumlah incident Jumlah emergency request Sosialisasi kepada user, mudah diakses dan digunakan. Standard prosedur setiap request (include PR, PO, WO). prosedur setiap request (include PR, PO, WO). Kecepatan mengakses SRM Status request update Penelusuran proses request Notification (Outlook) Persentasi RFC yang di reject Percentasi request yang menyebabkan incident Jumlah request pending karena vendor purchase Flow proses request

32 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 Persentasi request reassigned Persentasi request yang diselesaikan oleh SPoC 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 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 Persentasi jumlah waktu untuk menyelesaikan request Jumlah request yang tidak di deliver sesuai waktu yang diharapkan Jumlah SLA yang sesuai target 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.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

33 2 : 21-40% 3 : 41-60% 4 : 61-80% 5 : % Namun untuk metrik-metrik yang ditandai dengan huruf tebal, penilaian Actual Operational ke nilai KPI adalah sebagai berikut: 1 : % 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 Pengukuran kinerja Pegawai IT Berikut adalah penilaian kinerja pegawai dari masing-masing departement menggunakan KPI setelah menerapakan ITIL V3 KPI CSF Department Criti Hig Medi Lo Criti Hig Medi Lo cal h um w cal h um w BWA IP Infrastructure Enterprise Information

34 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 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 V 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

35 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 α 2 dengan, Vˆ( y) s V ˆ 2 ( y) = n s 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. 2 = n i= 1 ( y i y) n 1 2 Gambar 4.11 Diagram Pengguna ITIL PT Bakrie Telecom mengimplementasikan Service Request Management, Incident Management, Problem Management, Knowledge Management dan 65

36 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 KEPENTINGAN Berikut 3.95adalah hasil survey perbandingan sistem request managemet dengan 9 11 sistem manual dan kepuasan mereka terhadap sistem yang baru KEPUASA N

37 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 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

38 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

39 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

40 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 Kepuasan SRM Lebih SR dan SRM 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

41 Tabel 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 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

42 Gambar 4.17 Hasil Survei Kepuasan User 72

43 4.5 Perbandingan Sebelum dan Sesudah penerapan SRM Service Request System Gambar 4.18 Service Request System Proses Flow Before After 73

44 Setelah menerapkan Service Request Management berdasarkan ITIL terdapat proses dengan status yang jelas. Sehingga memudahkan dalam tracking process. Informasi perubahan status akan diinformasikan melalui 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 Request priority Before NA After Critical High Medium Low 74