UNIVERSITAS INDONESIA MANAJEMEN OPERASI LAYANAN IT HELPDESK: STUDI KASUS DI PT TOYOTA ASTRA FINANCIAL SERVICES KARYA AKHIR

UNIVERSITAS INDONESIA

MANAJEMEN OPERASI LAYANAN IT HELPDESK: STUDI KASUS DI PT TOYOTA ASTRA FINANCIAL SERVICES

KARYA AKHIR

BAYU KUSUMA WIJAYA 1306346834

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JANUARI 2015

Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015

UNIVERSITAS INDONESIA

MANAJEMEN OPERASI LAYANAN IT HELPDESK: STUDI KASUS DI PT TOYOTA ASTRA FINANCIAL SERVICES

KARYA AKHIR Diajukan sebagai salah satu syarat untuk memperoleh gelar Magister Teknologi Informasi

BAYU KUSUMA WIJAYA 1306346834

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JANUARI 2015




KATA PENGANTAR

Puji syukur penulis panjatkan kehadirat Allah SWT karena berkah dan rahmatNya akhirnya penuis dapat menyelesaikan Karya Akhir ini. Karya Akhir ini memiliki judul Manajemen Operasi Layanan IT Helpdsesk: Studi Kasus di PT Toyota Astra Financial Services. Penulisan Karya Akhir ini dilakukan sebagai salah satu syarat dalam mencapai gelar Magister Teknologi Informasi di Universitas Indonesia. Penulis menyadari bahwa sangatlah sulit bagi penulis untuk menyelesaikan penelitian ini tanpa bantuan dan bimbingan dari berbagai pihak. Untuk itu, penulis mengucapkan terima kasih sebesar-besarnya kepada: 1. Bapak Riri Satria, S.Kom., M.M. dan Ibu Betty Purwandari, S.Kom., M.Sc., Ph.D selaku dosen pembimbing yang telah menyediakan waktu, tenaga, dan pikiran untuk mengarahkan dan membimbing penulis dalam menyusun dan menyelesaikan Karya Akhir ini. 2. Bapak Ir. Wahyu Catur Wibowo, M.Sc., Ph.D. dan Bapak Denny, S.Kom., M.I.T., Ph.D. selaku penguji yang telah memberikan saran dan kritik yang membangun dalam penyelesaian Karya Akhir ini. 3. Seluruh dosen yang telah memberikan ilmu dan menjadi inspirasi bagi selama penulis menjadi mahasiswa pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer – Universitas Indonesia. 4. Seluruh staff pada sekretariat Magister Teknologi Informasi, Fakultas Ilmu Komputer – Universitas Indonesia yang telah membantu jalannya perkuliahan dengan lancar. 5. Orang tua penulis, Alm. Bapak Dandan Widoyo dan Ibu Sri Ratnawati, kakek penulis, Alm. Suratman Wiryosudarmo, dan adik penulis, Topan Sukma Wijaya, yang telah terus memberikan bantuan dukungan moral dan material.

iv

Universitas Indonesia


6. Bapak Teddy Suryawan sebagai IT Development Department Head, Bapak Galaxi dan Ibu Jeanette Septaviani sebagai Supervisor dan IT Analyst, serta pimpinan maupun staf PT Toyota Astra Financial Services yang telah membantu dalam usaha perolehan data yang diperlukan dalam penelitan. 7. Ibu Evarisma Wulandari dan teman-teman Magister Teknologi Informasi, Fakultas Ilmu Komputer – Universitas Indonesia, khususnya kelas 2013 SB yang telah membantu saya dalam perkuliahan maupun penyelesaian Karya Akhir ini. Akhir kata, saya berharap Allah SWT berkenan membalas kebaikan semua pihak yang telah membantu. Semoga Karya Akhir ini membawa manfaat bagi pengembangan ilmu.

Jakarta, 06 Januari 2015

Penulis

v




ABSTRAK

Nama : Bayu Kusuma Wijaya Program Studi : Magister Teknologi Informasi Judul : Manajemen Operasi Layanan IT Helpdesk: Studi Kasus di PT Toyota Astra Financial Services Institusi keuangan seperti perusahaan pembiayaan sangat memanfaatkan teknologi informasi (TI) dalam menjalankan proses bisnisnya agar segala transaksi keuangan yang dilakukan tercatat dan dapat dipertanggungjawabkan. Dukungan operasional harian dari sisi teknologi informasi pun menjadi penting. Hal ini kemudian membuat peran IT Helpdesk dalam melayani permintaan-permintaan bantuan dan pemecahan masalah dari pengguna baik perangkat keras, perangkat lunak, maupun infrastruktur jaringan menjadi sangat penting. Diharapkan IT Helpdesk memberikan respon atas permintaan yang masuk dengan efektif dan efisien. Namun layanan TI yang diberikan IT Helpdesk saat ini belum dapat diperkirakan waktu penyelesaiannya. Salah satu penyebabnya adalah layanan TI pada IT Helpdesk belum didukung dengan adanya manajemen operasi layanan IT Helpdesk secara formal. Penelitian ini bertujuan untuk menyusun proses-proses operasi layanan TI Helpdesk dan rekomendasi fitur-fitur yang harus dimiliki oleh aplikasi yang digunakan oleh tim IT Helpdesk. Diharapkan dengan adanya prosesproses dan peralatan/tools yang efektif dan efisien dapat meningkatkan kualitas layanan TI yang diberikan oleh IT Helpdesk.

Kata Kunci: Manajemen, Operasi Layanan, Layanan TI, Manajemen Operasi layanan TI, IT Helpdesk

vii



ABSTRACT

Name : Bayu Kusuma Wijaya Study Program: Magister Teknologi Informasi Title : IT Helpdesk Service Operation Management : A Case Study of PT Toyota Astra Financial Services Financial institution as finance company is very depending on information technology (IT) for running its business process in order to ensure every financial transactions that has been executed are recorded and can be accounted. Daily operational support from information technology has become very important. IT Helpdesk’s role in providing service for many requests and problem solving for users related to hardware, software, and network infrastructure are very crucial. IT Helpdesk are expected to respond the incoming requests effectively and efficiently. But currently IT Helpdesk could not give expected time to resolve request for IT services which they provided. One of the reasons is IT Helpdesk is not yet supported with a formalized IT Helpdesk service operation management. The purpose of this research is to develop IT Helpdesk service operation management and recognize the required features of tools to be used by IT Helpdesk team. Hopefully the new processes and tools features can improve the quality of IT service provided by IT Helpdesk.

Keywords: Management, Service Operation, IT Service, Layanan TI, Service Operation Management, IT Service Opeation, IT Helpdesk

viii



DAFTAR ISI

HALAMAN JUDUL ..............................................................................................1 HALAMAN PERNYATAAN ORISINALITAS ................................................ ii HALAMAN PENGESAHAN .............................................................................. iii KATA PENGANTAR .......................................................................................... iv HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI ........................ vi KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS ........................... vi ABSTRAK ........................................................................................................... vii ABSTRACT ........................................................................................................ viii DAFTAR ISI ......................................................................................................... ix DAFTAR GAMBAR ............................................................................................ xi DAFTAR TABEL ............................................................................................... xii BAB I PENDAHULUAN .......................................................................................1 1.1 Latar Belakang ...........................................................................................1 1.2 Perumusan Masalah ...................................................................................4 1.3 Pertanyaan Penelitian .................................................................................6 1.4 Batasan Penelitian ......................................................................................7 1.5 Tujuan Penelitian .......................................................................................7 1.6 Tujuan dan Manfaat Penelitian ..................................................................7 1.7 Sistematika Penelitian ................................................................................7 BAB II TINJAUAN PUSTAKA............................................................................9 2.1 Layanan Teknologi Informasi ....................................................................9 2.2 IT Helpdesk ..............................................................................................11 2.3 Tata Kelola TI ..........................................................................................13 2.4 Manajemen Layanan TI ...........................................................................14 2.4.1 Operasi Layanan TI ......................................................................... 17 2.5 Soft System Methodology (SSM) ..............................................................25 2.6 Pengumpulan data kualitatif ....................................................................30 2.7 Focus Group Discussion ..........................................................................32 2.8 Benchmarking ..........................................................................................34 2.9 Standard Operating Procedure................................................................35 2.10 Penelitian Sebelumnya .............................................................................36 2.10.1 Towards an Improved IT Service Desk System and Processes: A Case Study ..................................................................................................... 36 2.10.2 Effective Implementation of Problem Management in ITIL Service Management .................................................................................................. 42 2.11 Tinjauan Metodologi penyusunan manajemen operasi layanan TI .........46 2.12 Theoretical Framework ...........................................................................47 BAB III METODOLOGI PENELITIAN ..........................................................50 3.1 Alur Metodologi Penelitian......................................................................50 3.2 Detil Alur Metodologi Penelitian.............................................................52 3.3 Metode Pengumpulan data .......................................................................55 BAB IV ANALISIS DAN PEMBAHASAN .......................................................58 4.1 Data Wawancara ......................................................................................58 4.1.1 Fungsi dan peran pada iCare ........................................................... 58 ix



4.1.2 Layanan iCare ................................................................................. 58 4.1.3 Operasi Layanan iCare .................................................................... 60 4.2 Artefak Aplikasi .......................................................................................62 4.2.1 Issue Log ......................................................................................... 62 4.2.2 E-Dora ............................................................................................. 64 4.3 Observasi di IT Helpdesk / iCare .............................................................68 4.4 Mengekspresikan Situasi Bermasalah......................................................71 4.5 Membuat root definition ..........................................................................71 4.6 Membuat model konseptual .....................................................................73 4.6.1 Benchmarking dengan PT Bussan Auto Finance ............................ 73 4.6.2 Operasi Layanan ITIL v3 ................................................................ 75 4.6.3 Model konseptual ............................................................................ 77 4.7 Membandingkan model konseptual dengan dunia nyata .........................82 4.8 Menyusun perubahan ...............................................................................83 4.8.1 Budaya Perusahaan ......................................................................... 83 4.8.2 Kebijakan Perusahaan ..................................................................... 86 4.8.3 Challenges implementasi ITIL ........................................................ 86 Manajemen masalah reaktif dan proaktif ........................................ 87 4.8.4 4.8.5 Perubahan yang diusulkan .............................................................. 88 4.8.6 Perubahan yang diterima ................................................................. 89 4.9 Model manajemen operasi layanan Toyota Astra Finance ......................91 4.10 Proses-proses manajemen operasi layanan Toyota Astra Finance ..........92 4.11 Usulan Tools ..........................................................................................104 4.12 Usulan SOP ............................................................................................106 4.12.1 Draft SOP Manajemen Event IT Helpdesk ................................... 106 4.12.2 Draft SOP Manajemen Insiden IT Helpdesk ................................ 108 4.12.3 Draft SOP Manajemen Masalah Proaktif IT Helpdesk ................. 111 4.12.4 Draft SOP Manajemen Masalah IT Helpdesk ............................... 112 4.13 Usulan Metrik Pengukuran Efektivitas dan Efisiensi ............................115 4.14 Analisis Dampak ....................................................................................118 BAB V KESIMPULAN DAN SARAN .............................................................120 5.1 Kesimpulan ............................................................................................120 5.2 Saran ......................................................................................................121 DAFTAR PUSTAKA .........................................................................................122 LAMPIRAN ........................................................................................................124

x



DAFTAR GAMBAR

Gambar 1.1. Toyota Financial Services di seluruh dunia ....................................... 2 Gambar 1.2. Fishbone Diagram .............................................................................. 5 Gambar 2.1 Tren penggunaan kerangka kerja dan standard external ................... 14 Gambar 2.2 Service Desk terpusat ........................................................................ 16 Gambar 2.3 Alur proses manajemen event ........................................................... 18 Gambar 2.4 Alur proses manajemen insiden ........................................................ 20 Gambar 2.5 Alur proses manajemen masalah ....................................................... 23 Gambar 2.6 Tahapan SSM .................................................................................... 25 Gambar 2.7 Rich Picture ....................................................................................... 27 Gambar 2.8 Model Konseptual ............................................................................. 29 Gambar 2.9 Agenda Focus Group The Winner’s Ink ........................................... 34 Gambar 2.10 Kerangka Berpikir ........................................................................... 49 Gambar 3.1 Metodologi penelitian ....................................................................... 51 Gambar 3.2 Metodologi penelitian ....................................................................... 52 Gambar 4.1 Tampilan input new issue pada aplikasi issue log............................. 63 Gambar 4.2 Informasi open new pada aplikasi issue log ...................................... 64 Gambar 4.3 Halaman muka aplikasi E-Dora ........................................................ 65 Gambar 4.4 Halaman input CDR pad aplikasi E-Dora ......................................... 66 Gambar 4.5 Rich picture kondisi saat ini .............................................................. 71 Gambar 4.6 Model konseptual .............................................................................. 78 Gambar 4.7 Model manajemen operasi layanan Toyota Astra Finance ............... 92 Gambar 4.8 Proses manajemen event ................................................................... 94 Gambar 4.9 BPMN manajemen event................................................................... 95 Gambar 4.10 Proses manajemen insiden .............................................................. 97 Gambar 4.11 BPMN manajemen insiden ............................................................. 98 Gambar 4.12 Proses manajemen masalah proaktif ............................................... 99 Gambar 4.13 BPMN manajemen masalah proaktif .............................................. 99 Gambar 4.14 Proses manajemen masalah ........................................................... 101 Gambar 4.15 BPMN manajemen masalah .......................................................... 102 Gambar 4.16 SOP Manajemen Event IT Helpdesk ............................................ 107 Gambar 4.17 SOP Manajemen Insiden IT Helpdesk (1) .................................... 109 Gambar 4.18 SOP Manajemen Insiden IT Helpdesk (2) .................................... 110 Gambar 4.19 SOP Manajemen Insiden IT Helpdesk (3) .................................... 111 Gambar 4.20 SOP Manajemen Masalah Proaktif ............................................... 112 Gambar 4.21 SOP Manajemen Masalah IT Helpdesk (1) ................................... 114 Gambar 4.22 SOP Manajemen Masalah IT Helpdesk (2) ................................... 115

xi



DAFTAR TABEL

Tabel 2.1 Perbandingan implementasi ITIL ......................................................... 46 Tabel 3.1 Tabel Pertanyaan ................................................................................... 56 Tabel 4.1 Tabel analisa CATWOE ....................................................................... 72 Tabel 4.2 Hasil benchmarking dengan BAF ......................................................... 75 Tabel 4.3 Perbandingan proses saat ini dengan operasi layanan ITIL v3 ............. 77 Tabel 4.4 Perbandingan model konseptual dengan dunia nyata ........................... 82 Tabel 4.5 Kesesuaian aktivitas model dengan budaya perusahaan ....................... 84 Tabel 4.6 Saran dari challenges implementasi ITIL ............................................. 87 Tabel 4.7 Saran dari FGD untuk usulan perubahan .............................................. 90 Tabel 4.8 Tabel fitur aplikasi helpdesk ............................................................... 104 Tabel 4.9 Tabel kesesuaian fitur aplikasi Redmine ............................................ 105 Tabel 4.10 Tabel metrik pengukuran efektivitas dan efisiensi operasi layanan . 116

xii



BAB 1 PENDAHULUAN

Bab ini memjabarkan latar belakang yang mendasari penelitian. Berdasarkan latar belakang tersebut kemudian dirumuskan masalah dan pertanyaan penelitian. Kemudian untuk memberi arah dan batasan penelitian maka selanjutnya dibahas tujuan, manfaat, dan ruang lingkup penelitian. 1.1

Latar Belakang

PT. Toyota Astra Financial Services, atau yang biasa disebut Toyota Astra Finance, merupakan perusahaan kerjasama antara Toyota Financial Services Corporation (TFSC) dan PT. Astra International Tbk (AI) yang ditandai dengan penandatangan kerjasama pada Oktober 2006. Toyota Astra Finance merupakan cabang ke-31 dari TFSC diseluruh dunia. Meskipun Toyota Astra Finance perusahaan baru tetapi kerjasama antara kedua induk perusahaan ini di Indonesia sudah terjalin lebih dari 30 tahun. Toyota Astra Finance memiliki tujuan untuk menjadi pilihan utama dalam menyediakan jasa layanan pembiayaan untuk kepemilikan kendaraan Toyota dengan menjunjung tinggi sikap profesionalisme, berusaha memberikan yang terbaik, memiliki semangat kerjasama yang berfokus kepada pelanggan. Toyota Astra Finance berusaha membantu mewujudkan impian pelanggan untuk memiliki kendaraan Toyota dengan menyediakan pelayanan yang mudah dan terjangkau. Saat ini Toyota Astra Finance memiliki 35 cabang diseluruh pulau Sumatera, Jawa, dan Kalimantan.

1



2

Gambar 1.1. Toyota Financial Services di seluruh dunia Sumber: TAFinance, 2014

Layanan yang berikan Toyota Astra Finance adalah: 1. Consumer Vehicle Financing Ditujukan kepada pelanggan yang membeli kendaraan untuk keperluan nonkomersial. 2. Business Vehicle Financing Ditujukan sebagai solusi pembiayaan yang didesain untuk mendukung bisnis pelanggan dan cocok untuk kebutuhan atas pembiayaan yang melibatkan unit kendaraan dalam jumlah besar. 3. Vehicle Financial Lease Ditujukan untuk badan usaha/perusahaan yang membutuhkan pembiayaan dalam bentuk penyewaan yang melibatkan jumlah unit kendaraan yang besar. Setiap tahun Toyota Astra Finance mengalami pemeriksaan keuangan sebanyak dua kali. Sebagai perusahaan pembiayaan, Toyota Astra Finance sangat memanfaatkan teknologi informasi (TI) dalam proses bisnisnya agar segala transaksi keuangan yang dilakukan tercatat dan dapat dipertanggungjawabkan. Dukungan teknologi informasi dalam pelaksanaan bisnis sehari-hari menjadi penting. Salah satu faktor yang mendukung hal tersebut Toyota Astra Finance adalah dengan adanya IT Helpdesk yang memberikan dukungan operasional harian dari sisi teknologi informasi. IT Helpdesk ini baru dibentuk pada tahun 2013 Universitas Indonesia


3

bersamaan dengan pergantian core system. Sebelum ada IT Helpdesk, semua permintaan layanan TI langsung masuk ke analis di departemen IT Development dan departemen IT Operation dengan dibantu dengan 2 orang admin TI. IT Helpdesk Toyota Astra Finance berlokasi di kantor cabang kelapa gading dan melayani kantor pusat dan 35 kantor cabang yang tersebar di Pulau Sumatera, Jawa, Kalimantan, Bali, dan Sulawesi. Permintaan layanan masuk melalui berbagai media seperti telepon, surat elektronik, dan formulir aplikasi. Layanan yang diberikan IT Helpdesk meliputi permintaan-permintaan bantuan oleh pengguna sampai pemecahan masalah perangkat keras dan perangkat lunak serta infrastruktur jaringan. IT Helpdesk tidak hanya memberikan dukungan terhadap aplikasi yang masuk kategori key operational saja, tetapi juga aplikasi-aplikasi yang masuk kategori aplikasi pendukung/support. Dengan rata-rata request sebanyak 1800 permintaan melalui aplikasi ticketing, 2700 permintaan melalui telepon, dan surel dari 700 pengguna tiap bulannya, maka IT Helpdesk memiliki peranan yang cukup penting dalam memberikan dukungan terhadap operasional harian Toyota Astra Finance. Pada organisasi IT Helpdesk terdapat agen teknologi informasi support untuk infrastruktur jaringan dan perangkat keras, agen teknologi informasi untuk perangkat lunak, dan supervisor untuk IT Helpdesk. Supervisor selain mengawasi dan menjalankan operasional IT Helpdesk juga berfungsi sebagai pemecah masalah tingkat kedua (2nd level support) jika permintaan tidak dapat diselesaikan ditingkat pertama (agen IT Helpdesk). Jika permintaan yang dieskalasi tidak dapat diselesaikan oleh supervisor di IT Helpdesk maka permintaan diteruskan ke analis departemen (2nd level), yaitu: departemen IT Development atau departemen IT Operation, dimana masing-masing departemen tersebut memiliki staf analis teknologi informasi yang spesifik untuk menangani permasalah perangkat keras, jaringan atau aplikasi tertentu. Saat ini secara organisasi IT Helpdesk adalah satuan kerja berada dibawah departemen IT Development.



4

1.2

Perumusan Masalah

Berdasarkan wawancara dengan IT Development Departement Head yang ada pada lampiran dan pengamatan langsung, kondisi ideal adalah agen IT Helpdesk perusahaan melakukan: 1. Pencatatan permintaan yang masuk. 2. Melakukan klasifikasi terhadap permintaan yang masuk. 3. Memberikan perkiraan lama waktu penyelesaian dari permintaan yang masuk. 4. Menentukan staf teknologi informasi yang menangani permintaan tersebut. 5. Melakukan pengawasan permintaan tersebut sampai permintaan tersebut terselesaikan. Sedangkan kondisi saat ini pada IT Helpdesk adalah agen IT Helpdesk hanya melakukan: 1. Pencatatan permintaan yang masuk. 2. Menentukan staf teknologi informasi yang menanganinya. 3. Melakukan pengawasan permintaan tersebut sampai permintaan tersebut terselesaikan. Dari uraian diatas, berikut adalah permasalahan yang menjadi Gap antara kondisi ideal dengan kondisi saat ini: 1. Agen IT Helpdesk tidak dapat melakukan klasifikasi terhadap permintaan yang masuk. 2. Agen IT Helpdesk tidak dapat memberikan perkiraan lama waktu penyelesaian dari permintaan yang masuk. Agen IT Helpdesk tidak dapat memberikan perkiraan lama waktu penyelesaian dari permintaan yang masuk. Padahal TI memiliki peranan yang cukup besar pada operasional bisnis Toyota Astra Finance. Permintaan yang masuk ke IT Helpdesk yang tidak bisa dipastikan lama penyelesaiannya dapat mengganggu operasional bisnis. Masalah ini yang diangkat oleh penulis dan kemudian dianalisis. Masalah tersebut dianalisis lebih mendalam untuk mencari akar-akar masalahnya menggunakan diagram Fishbone. Hasil analisis terhadap akar-akar masalah tersebut dituangkan dalam Gambar 1.2.



5

Gambar 1.2. Fishbone Diagram Pada diagram fishbone gambar 1.2 terlihat bahwa domain permasalahan dapat dibagi menjadi 4, yaitu Method, Material, Machinery, dan People. Pada sisi Method yang jadi permasalahan adalah pengawasan permintaan yang dieskalasi sulit. Hal ini karena setiap penanganan permintaan dilakukan secara manual. Sehingga sulit untuk mengawasi penangan aplikasi yang dieskalasi. Selain itu belum ada panduan formal mengenani penangan permintaan. Hal ini disebabkan belum ada manajemen layanan IT Helpdesk secara formal. Beberapa pendataan permintaan tidak real time karena pendataan kadang dilakukan setelah permintaan dikerjakan. Hal ini karena ada beberapa permintaan genting yang harus langsung dikerjakan karena ada pelanggan yang sedang menunggu didepan petugas. Pemanfaatan tools yang belum maksimal karena tools saat ini hanya digunakan sebagai sarana komunikasi permintaan ke pengguna. Pada sisi Material, yang menjadi permasalahan adalah permintaan yang masuk ke IT Helpdesk sangat beragam karena layanan IT Helpdesk yang diberikan juga beragam. Kadang beberapa permintaan tidak hanya berhenti di agen IT Helpdesk, tetapi harus dieskalasi ke IT Analyst karena keterbatasan kompetensi dari agen IT Universitas Indonesia


6

Helpdesk. Permintaan yang masuk dapat melalui banyak saluran informasi seperti surel, telepon, aplikasi ticketing request, maupun pengguna yang mendatangi agen IT helpdesk secara langsung. Permintaan yang masuk meningkat diakhir bulan. Hal ini sejalan dengan cenderung memuncaknya aplikasi kredit menjelang closing operational di akhir bulan. Pihak dealer memiliki budaya mengejar sasaran penjualan menjelang akhir bulan sehingga berpengaruh kepada value chain berikutnya yaitu pembiayaan mobil. Pada sisi People, yang menjadi masalah adalah agen IT Helpdesk yang mengalami overload menjelang akhir bulan. Jumlah agen IT Helpdesk yang menangani permintaan adalah 4 orang sedangkan perbulannya permintaan yang masuk dapat mencapai 1800 permintaan. Permintaan yang masuk memuncak diakhir bulan dan menurun diawal bulan. Pada sisi Machinery, yang menjadi masalah adalah belum ada tools penyelesaian masalah dari permintaan yang ada terpisah-pisah tergantung dengan jenis permintaan dan masalah yang dihadapi sehingga sulit memperkirakan waktu penyelesaian. Hal ini disebabkan karena perilaku pengembangan tools yang dibuat secara reaktif. Dari analisis masalah menggunakan teknik fishbone diatas, penulis memfokuskan pada belum adanya manajemen operasi layanan IT Helpdesk secara formal. Adanya manajemen operasi layanan membuat adanya panduan formal mengenai penanganan permintaan yang masuk ke IT Helpdesk. Sehingga agen IT Helpdesk dapat memberikan perkiraan lama waktu penyelesaian dari setiap permintaan yang masuk. 1.3

Pertanyaan Penelitian

Perumusan masalah menunjukan bahwa tidak ada manajemen layanan IT Helpdesk secara formal atas permintaan yang masuk ke IT Helpdesk PT Toyota Astra Financial Services. Apabila dibandingkan dengan daur hidup layanan pada best practice ITIL, saat ini layanan IT Helpdesk sudah berada di fase operasi layanan. Atas dasar perumusan masalah yang sudah dijabarkan diatas, penulis menetapkan pertanyaan penelitian sebagi berikut: Universitas Indonesia


7

“Bagaimana menyusun manajemen operasi layanan IT Helpdesk di PT Toyota Astra Financial Services?” 1.4

Batasan Penelitian

Penelitian dilakukan di IT Helpdesk PT Toyota Astra Financial Services dengan ruang lingkup sebagai berikut: 1. Studi kasus penelitian di IT Helpdesk PT Toyota Astra Financial Services. 2. Membuat prosedur operasi layanan IT Helpdesk di PT Toyota Astra Financial Services. 3. Membuat saran fitur perangkat lunak yang sebaiknya dimiliki IT Helpdesk di PT Toyota Astra Financial Services. 1.5

Tujuan Penelitian

Berdasarkan pertanyaan penelitian yang telah ditetapkan oleh penulis, maka tujuan dari penelitian ini adalah menghasilkan manajemen operasi layanan IT Helpdesk pada PT Toyota Astra Financial Services. 1.6

Tujuan dan Manfaat Penelitian

Dengan penyusunan manajemen operasi layanan IT Helpdesk diharapkan dapat memberikan manfaat. Manfaat dari sisi praktis adalah sebagai berikut: 1. Dapat menjadi panduan bagi IT Helpdesk dalam memberikan operasi layanan-layanan TI di PT Toyota Astra Financial Services. 2. Meningkatkan kualitas operasi layanan-layanan yang diberikan oleh IT Helpdesk di PT Toyota Astra Financial Services. Manfaat dari sisi akademis adalah dapat memberikan kontribusi bagi dunia pendidikan sebagai pelengkap referensi penyusunan manajemen operasi layanan TI pada IT Helpdesk. 1.7

Sistematika Penelitian

Penelitian terbagi menjadi lima bab yang masing-masing Bab membahas hal berikut: Universitas Indonesia


8

BAB I PENDAHULUAN Menguraikan latar belakang permasalahan yang terjadi, perumusan masalah, tujuan penelitian, batasan masalah, dan sistematika penulisan. BAB II TINJAUAN PUSTAKA Menguraikan semua teori yang terkait dengan penelitian ini berdasarkan literaturliteratur yang ada sebagai acuan serta tinjuan pustaka. BAB III METODOLOGI PENELITIAN Menguraikan tahapan-tahapan yang dilakukan oleh penulis dalam penelitian ini BAB IV HASIL DAN PEMBAHASAN Menguraikan hasil serta proses yang dilakukan dengan mengelola data-data yang didapatkan penulis sebagai bahan analisis yang sesuai dengan kebutuhan evaluasi. BAB V KESIMPULAN DAN SARAN Menyampaikan hasil yang didapatkan dari penelitian penulis serta saran penulis sebagai perbaikan selanjutnya untuk masa yang akan datang.



BAB 2 TINJAUAN PUSTAKA

Bab ini berisi pembahasan teori, penelitian sebelumnya, dan metodologi yang akan digunakan dalam penelitian ini. Teori-teori yang dibahas antara lain layanan teknologi informasi, IT Helpdesk, manajemen layanan TI, dan Soft System Methodology. Pada bagian akhir dijabarkan kerangka teoritis yang merupakan rangkuman seluruh literatur yang dibahas dan dijadikan sebagai dasar penelitian. 2.1

Layanan Teknologi Informasi

Addy (2007) mendefiniskan layanan sebagai kapabilitas yang didefinisikan atau himpunan deliverables yang ditujukan untuk memuaskan kebutuhan yang sudah didefinisikan menggunakan sumber daya (manusia, benda, dan peralatan) dan menggunakan proses penghantaran yang terdefinisi. Hal ini dapat meliputi penyediaan instalasi atau pemeliharaan yang diberikan penjaja jasa perangkat lunak. Pada lingkup Teknologi Informasi (TI) korporasi yang dimaksud pelanggan dapat berupa pengguna. Ada beberapa metode dasar yang untuk mendefinisikan katalog penuh dari Layanan TI menurut Addy (2007)antara lain: 1. Model berorientasi fungsional/teknis Layanan didefinisikan berdasarkan peran fungsional yang bertanggung jawab dalam memberikan layanan dan/atau deskripsi teknis dari komponen utama dalam layanan itu sendiri. Model ini mengasumsikan bahwa orang yang berkerja dengan layanan ini mengerti tentang apa yang dikerjakan oleh beragam tim yang ada dan bagaimana tim-tim tersebut berkerjasama memberikan layanan kepada pengguna. Misalnya layanan berdasarkan disiplin teknis seperti jaringan, basis data, dan operasi TI. 2. Model berorientasi sistem/aplikasi Layanan direpresentasikan berdasarkan sistem atau aplikasi yang dilihat dan dipergunakan oleh pengguna misalnya surel, ERP, Otomasi penjualan, dan 9 Universitas Indonesia


10

lain-lain. Definisi dengan model mudah dimengerti oleh pengguna tetapi kadang tidak dapat mengenkapsulasi layanan yang diberikan dalam skala yang utuh. 3. Model layanan berorientasi bisnis Model ini cukup rumit karena mendefinisikan layanan pendukung proses bisnis. Dimana satu layanan bisnis dapat membutuhkan kontribusi dari fungsi TI yang beragam dan luas baik dari keamanan dan jaringan, aplikasi, basis data, hingga bantuan pengguna. Contohnya adalah sebagai berikut: a. Penggajian Bulanan: ERP, sistem penggajian, transfer bank, printer, jaringan, dan sebagainya. b. Toko Online: Website hosting, sistem pengaturan pemesanan, ERP, CRM, dan gateway otorisasi pembayaran kartu kredit. 4. Model berorientasi layanan (Support centric services) Model ini memetakan dukungan dari kapabilitas TI yang spesifik sebagai sebagai layanan. a. Dukungan workstation: layanan umum yang mencakup perangkat keras pengguna, konektivitas jaringan, dan aplikasi perangkat lunak inti. b. Dukungan mobile pengguna: layanan mencakup pengaturan modem, konfigurasi komunikasi, isu konektivitas, diagnosa masalah akses VPN, dan lain-lain. c. Dukungan aplikasi spesifik: dukungan teknis untuk aplikasi yang bukan termasuk aplikasi inti. 5. Model Ongoing subscription/Subliminal Services Memetakan layanan yang tidak dikenali oleh pengguna tetapi digunakan oleh pengguna dan tanpa adanya layanan ini pengguna tidak dapat melakukan apapun. Subliminal services mencakup infrastruktur jaringan utama dan pengaturan komunikasi serta keamanan dasar dan alat penyimpanan data, contohnya manajemen penyimpanan data dan akses dan keamanan sistem Universitas Indonesia


11

(administrasi login, autentifikasi sistem, manajemen kata sandi, pemutakhiran antivirus, dan lain-lain) 6. Layanan transaksional Layanan yang kadang-kadang digunakan untuk untuk memenuhi kebutuhan bisnis. Layanan meliputi: a. Penyediaan perangkat keras b. Penyediaan perangkat lunak c. IMAC (installation, move, and change) 7. Model berbasis peran Model layanan berbasis peran terkait dengan layanan TI yang dibutuhkan untuk melakukan suatu fungsi pekerjaan spesifik. Sebagai contoh adalah peran sales eksekutif didalamnya mencakup layanan akses dan keamanan sistem, workstation support, dan mobile user support. 2.2

IT Helpdesk

Menurut Marko Jäntti (2012) Service Desk dikenal dengan banyak nama seperti Helpdesk, Support Center, Information Center, IT solutions center atau technical support. Service Desk ini adalah titik kontak penting antara pelanggan, pengguna, penyedia layanan IT, dan penyedia layanan third-party. Jäntti menjelaskan bahwa tujuan dari agen IT Service Desk adalah untuk mencatat, mengkategorikan, melakukan diagnosa, dan menyelesaikan kasus dari pelanggan dan pengguna. Kasus ini dapat berupa kegagalan perangkat keras dan perangkat lunak, permintaan layanan seperti melakukan reset password, komplain atau umpan balik. Menurut Beisse (2013) layanan user support pada organisasi sering memberikan beragam layanan. Keragamanan layanan yang diberikan bergantung pada tujuan organisasi, kebutuhan spesifik dari karyawan atau pelanggan, dan sumber daya organisasi. Berikut adalah layanan yang umum diberikan:



12

1. Helpdesk karyawan, hotline, atau layanan berbicara untuk memberikan informasi. 2. Memberikan asistensi pemecahan masalah teknis untuk perangkat keras, perangkat lunak, atau masalah jaringan. 3. Menemukan informasi untuk membantu pengguna. 4. Mengevaluasi produk perangkat keras, perangkat lunak, dan jaringan. 5. Mengkoordinasikan standard support dalam lingkup organisasi. 6. Melakukan penaksiran kebutuhan dan memberikan layanan asistensi pengadaan untuk pengguna. 7. Memberikan layanan asistensi instalasi sistem. 8. Memberikan pelatihan pada sistem dan prosedur komputer. 9. Menyiapkan dokumentasi penggunaan komputer. 10. Melakukan kegiatan manajemen fasilitas komputer. 11. Membantu pengguna dalam proyek pengembangan perangkat lunak. Agen helpdesk sebaiknya juga melakukan hal-hal berikut: 1. Merespon permintaan informasi produk. 2. Memberikan solusi untuk masalah yang umum. 3. Memasarkan atau menjual produk dan layanan, termasuk ad-ons dan upgrade. 4. Menerima dan mencatat komplain dari pengguna terkait fitur produk. 5. Menangani klaim garansi dan mengotorisasi retur atau penukaran produk. Beberapa posisi spesifik membutuhkan knowledge, skills, Ability (KSA) yang spesifik juga untuk menjalankan pekerjaannya. Berikut KSA yang sebaiknya dimiliki oleh agen Helpdesk. 1. Knowledge Universitas Indonesia


13

Hal yang harus diketahui pekerja untuk menjalankan pekerjaannya. Untuk posisi agen helpdesk maka hal yang perlu diketahui adalah: a. Pengetahuan atas teknologi komputer, termasuk perangkat keras, perangkat lunak, dan jaringan b. Pengetahuan atas Sistem Operasi Windows. 2. Skills Setiap posisi memerlukan keterampilan yang spesifik agar dapat mengerjakan pekerjaan. Agen helpdesk membutuhkan keterampilan sebagai berikut: a. Keterampilan dalam memecahkan masalah sistem. b. Keterampilan komunikasi telepon dan interpersonal. 3. Ability Setiap

posisi

memerlukan

kemampuan

khusus

untuk

menjalankan

pekerjaannya. Berikut adalah kemampuan yang harus dimiliki agen helpdesk. a. Kemampuan untuk mengelola tingkat kerahasiaan yang sesuai/wajar. b. Kemampuan untuk menyiapkan laporan dan dokumentasi teknis. 2.3

Tata Kelola TI

Menurut Bon (2007) tata kelola TI terdiri dari suatu kerangka kerja dari struktur, proses, dan mekanisme relasional yang komprehensif. “Struktur” melibatkan adanya fungsi yang bertanggung jawab seperti eksekutif TI dan komite TI yang beragam anggotanya. “Proses” merujuk kepada pengambilan keputusan dan pengawasan TI yang strategis. “Mekanisme relasional” melibatkan partisipasi dan kemitraan, dialog strategis, dan pembelajaran bersama antara bisnis dan TI. Ada perbedaan besar antara tata kelola dan manajemen dimana tata kelola memungkinkan pembuatan suatu pengaturan sehingga yang lain dapat mengelola tugas mereka dengan efektif. Sehingga Tata kelola TI dan dan manajemen TI adalah dua entitas berbeda. Manajemen layanan TI dapat dimasukan kedalam ranah manajemen TI, yang sudah meninggalkan ranah tata kelola TI. Universitas Indonesia


14

2.4

Manajemen Layanan TI

Bon (2007) mendefinisikan layanan sebagai kegiatan memberikan nilai/value kepada pengguna dengan memfasilitasi pengguna dengan hasil yang ingin dicapai tanpa adanya kepemilikan biaya ataupun resiko. Sedangkan manajemen layanan adalah suatu kumpulan kapabilitas khusus organisasi untuk memberikan nilai/value kepada pengguna dalam bentuk layanan-layanan. Manajemen layanan TI memiliki framework dari best practice yang banyak digunakan yaitu ITIL. Dengan menggunakan framework yang populer maka diharapkan output yang dihasilkan menjadi efektif dan efisien serta mempermudah organisasi dalam mencari rujukan penerapan lanjutan dikemudian hari.

Gambar 2.1 Tren penggunaan kerangka kerja dan standard external Sumber: IT Governance Institute (2011)



15

ITIL merupakan kependekan dari Information Technology Infrastructure Library. ITIL terbuat dari serangkaian best practice yang ditemukan dalam penyediaan layanan TI. Menurut Bon (2007), ITIL memberikan pendekatan sistematis untuk memberikan kualitas layanan TI. Saat ini ITIL sudah mencapai versi 3. ITIL versi 3 fokus kepada daur hidup layanan dan bagaimana komponen manajemen layanan saling terhubung. Daur hidup layanan terdiri dari 5 fase: 1. Perencanaan Layanan: fase desain, pengembangan, dan implementasi manajemen layanan sebagai suatu sumber daya strategis. 2. Desain Layanan/Perancangan Layanan: fase mendesain pengembangan layanan IT yang tepat, meliputi arsitektur, proses-proses, kebijakan, dan dokumen-dokumen. Tujuan utama mendesain adalah memenuhi kebutuhan bisnis saat ini dan yang akan datang. 3. Transisi Layanan: Fase pengembangan dan peningkatan kapabilitas untuk transisi layanan baru dan termodifikasi ke lingkungan kerja yang sedang berjalan. 4. Operasi Layanan: Fase memenuhi keefektifan dan efisiensi dalam menyediakan dan memberikan layanan dalam menjamin nilai/value yang diberikan kepada pengguna dan penyedia layanan. 5. Peningkatan Layanan yang Berkelanjutan: Fase membuat dan memelihara nilai/value untuk pengguna melalui suatu desain peningkatan, dan pengenalan layanan serta operasi.



16

Gambar 2.2 Service Desk terpusat Sumber: OGC (2007)

Fungsi yang ada pada organisasi IT Helpdesk adalah sebagai berikut: 1. Service Desk Titik kontak utama untuk pengguna saat ada gangguan layanan, permintaan layanan, atau permintaan perubahan. Agar tim Service Desk dapat berkerja secara efektif maka fungsi ini dipisahkan dari fungsi operasi layanan yang lain. Ada baiknya jika bantuan teknis secara detil dapat langsung ditawarkan kepada pengguna pada telepon pertama kali sehingga staf technical management untuk ada di Service Desk tetapi tidak berarti bahwa Service Desk menjadi bagian dari fungsi technical management. Justru staff technical management yang sedang berada di service desk berhenti perannya sebagai staf technical management dan menjadi bagian dari fungsi service desk untuk sementara waktu. 2. Technical Management Memberikan sumber daya dan skil teknis yang detail yang dibutuhkan untuk mendukung operasi yang sedang berjalan pada infrastruktur TI. Peran technical management mencakup perancangan, pengujian, release, dan peningkatan layanan TI. 3. IT Operation Management



17

Fungsi ini bertanggung jawab untuk operasional harian yang dibutuhkan untuk mengatur infrastruktur TI. 4. Application Management Fungsi ini bertanggung jawab untuk mengatur aplikasi sepanjang daur hidup aplikasi. Application Management mendukung dan menjaga operasional aplikasi dan juga berperan dalam hal perancangan, pengujian, dan peningkatan aplikasi. 2.4.1

Operasi Layanan TI

Menurut OGC (2007) pada operasi layanan, terdapat proses-proses sebagai berikut: 1. Manajemen Event: proses yang mengawasi semua peristiwa/event yang terjadi melalui infrastruktur TI untuk menjalankan operasional normal dan juga mendeteksi dan melakukan eskalasi kondisi pengecualian. Berikut adalah alur proses manajemen event.



18

Gambar 2.3 Alur proses manajemen event Sumber: OGC (2007) Universitas Indonesia


19

Pengukuran metrik untuk mengetahui efektivitas dan efisiensi dalam manajemen event adalah sebagai berikut: a. Jumlah event per kategori. b. Jumlah event per signifikansi. c. Jumlah dan persentase dari event yang membutuhkan intervensi manusia dan jumlah yang ditangani. d. Jumlah dan persentase event yang mengakibatkan insiden atau perubahan. e. Jumlah dan persentase event yang diakibatkan masalah yang sudah ada atau known-error. f. Jumlah dan persentase dari event yang berulang atau terduplikasi. g. Jumlah dan persentase dari event yang mengindikasikan isu kinerja. h. Jumlah dan persentase dari event yang mengindikasikan potensi isu ketersediaan. i. Jumlah dan persentase dari tiap event per platform atau aplikasi. j. Jumlah dan rasio event dibandingkan dengan jumlah insiden. 2. Manajemen Insiden: manajemen insiden berkonsentrasi mengembalikan layanan

kepada

pengguna

dalam

tempo

secepat-cepatnya

untuk

meminimalisir dampak kepada bisnis. Berikut adalah alur manajemen insiden menurut OGC.



20

Gambar 2.4 Alur proses manajemen insiden Sumber: OGC (2007) Universitas Indonesia


21

Pada manajemen masalah terdapat beberapa ukuran untuk mengetahui efisiensi dan efektivitas dari proses manajemen insiden. Berikut adalah ukuran yang dimaksud: a. Total jumlah insiden. b. Total Insiden yang didetailkan pada status insiden. c. Jumlah insiden saat ini yang backlog. d. Jumah dan persentase insiden major. e. Rata-rata waktu yang dibutuhkan untuk mencapai resolusi insiden. f. Persentase insiden yang ditangani yang masih didalam waktu respon yang disepakati. g. Biaya rata-rata per insiden. h. Jumlah insiden yang terbuka kembali (reopened) dibandingkan dengan persentase total. i. Jumlah dan persentase insiden yang tidak ditugaskan dengan benar. j. Jumlah dan persentase insiden yang memiliki kategori yang tidak tepat. k. Persentase insiden yang diselesaikan tanpa eskalasi (first point contact). l. Jumlah dan persentase insiden yang diproses per agen. m. Jumlah dan persentase insiden yang diselesaikan tanpa perlu kunjungan ke lokasi. n. Jumlah insiden per waktu dalam sehari untuk mengetahui puncak beban dan meastikan sumber daya mencukupi. 3. Manajemen Masalah: manajemen masalah melibatkan analisis akar masalah untuk menentukan dan menyelesaikan penyebab kejadian/event dan insiden, aktivitas proaktif untuk mendeteksi dan mencegah masalah Universitas Indonesia


22

atau insiden dikemudian hari dan sub-proses error yang sudah diketahui untuk mempercepat diagnosa dan resolusi jika insiden terjadi dimasa depan. Untuk mengukur efektivitas dan efisiensi dari manajemen masalah OGC (2007) memberikan rekomendasi pengukuran sebagai berikut: a. Jumlah total masalah yang tercatat dalam suatu periode. b. Persentase masalah yang diselesaikan dalam target SLA. c. Jumlah dan persentase masalah yang melebihi target waktu resolusi. d. Jumlah backlog masalah dan trend masalah. e. Rata-rata biaya penanganan masalah. f. Jumlah masalah major. g. Persentase dari peninjauan masalah major yang berhasil dilakukan. h. Jumlah Known-Error yang ditambahkan ke dalam Kown-Error Database. i. Persentase akurasi dari Kown-Error Database. j. Persentase peninjauan masalah major yang selesai dilakukan dan tepat waktu. Berikut adalah alur manajemen masalah menurut OGC (2007).



23

Gambar 2.5 Alur proses manajemen masalah Sumber: OGC (2007) Universitas Indonesia


24

4. Pemenuhan Permintaan: pemenuhan permintaan melibatkan manajemen permintaan pengguna yang tidak dimasukan sebagai insiden dari hambatan atau gangguan layanan yang tidak diduga. Untuk pemenuhan permintaan didapatkan pengukuran efektivitas dan efisiensi sebagai berikut: a. Jumlah permintaan layanan. b. Permintaan layanan pada tiap tahap. c. Jumlah backlog saat ini. d. Waktu rata-rata penyelesaian penanganan tiap jenis permintaan layanan. e. Jumlah dan persentase permintaan layanan yang selesai dalam batas waktu yang disepakati. f. Rata-rata biaya per permintaan layanan. g. Tingkat kepuasan pelanggan dari penanganan permintaan melalui survei. 5. Manajemen Akses: manajemen akses adalah proses pemberian akses pengguna yang diberi otoritas

untuk menggunakan layanan dan juga

mencegah akses dari user yang tidak memiliki otoritas. Manajemen akses memiliki ukuran yang dipergunakan untuk mengukur efesiensi dan efektivitas manajemen akses sebagai berikut: a. Jumlah permintaan akses. b. Akses yang diberikan per pengguna dan departemen. c. Akses yang diberikan oleh departemen atau pemberian akses individual. d. Jumlah insiden yang membutuhkan reset hak akses. e. Jumlah insiden yang disebabkan kesalahan pemberian akses.



25

2.5

Soft System Methodology (SSM)

Menurut Jackson (2003), Soft System Methodology (SSM) adalah sebuah metodologi yang memungkinkan intervensi dalam situasi bermasalah dimana mempertahankan relasi/hubungan sama pentingnya dengan mencari tujuan, dan menjawab pertanyaan tentang “apa” yang seharusnya kita lakukan sama pentingnya dengan menentukan “bagaimana” untuk melakukannya. SSM dewasa ini digunakan baik oleh akademisi maupun praktisi dan menyebar ke banyak negara di luar Inggris. SSM dapat direpresentasikan kedalam 7 tahap. Berikut adalah gambaran mengenai tahapan tersebut.

Gambar 2.6 Tahapan SSM Sumber: Jackson (2003)

1. Situasi bermasalah Pada tahap ini dilakukan identifikasi dari situasi bermasalah yang memerlukan perhatian. 2. Mengekspresikan situasi bermasalah Pada tahap ini situasi bermasalah harus ditunjukan, tidak secara sistem tetapi dalam bentuk rich picture. Tujuannya untuk mendapatkan dan menyebarkan Universitas Indonesia


26

pemahaman kreatif dari situasi bermasalah. Rich picture disusun dengan mengumpulkan informasi tentang struktur dan proses saat berkerja. 3. Root definition dari aktivitas sistem dengan tujuan yang relevan Pada tahap ini beberapa aktivitas manusia pada sistem yang relevan, yang berpotensi menawarkan wawasan dari situasi bermasalah, dipilih dan dari ini definisi akar dibangun. Definisi akar harus diformulasikan untuk menangkap intisari dari sistem terkait dan meyakinkan bahwa ini mendapat perhatian untuk menjadi faktor dalam CATWOE (Customers, Actors, Transformation process, World view, Owners and Environtmental contraints). 4. Model konseptual dari sistem yang relevan Definisi akar ini digunakan untuk membangun model konseptual. Model konseptual awalnya berisi 7 atau lebih aktivitas terstruktur dalam urutan logika dan merepresentasikan aktivitas minimal yang harus dilakukan untuk mendapatkan transformasi yang diinginkan pada root definition. Aktivitasaktivitas ini disebut holons. 5. Membandingkan model dengan dunia nyata Tahap ini bertujuan untuk memberikan materi untuk debat tentang perubahan yang mungkin dilakukan diantara peserta yang tertarik dengan situasi bermasalah. 6. Perubahan-perubahan (diinginkan secara sistem, dan feasible/dimungkinkan secara kultural) Tahap ini merupakan tahap pengembangan akomodasi diantara aktor yang mempunyai perhatian mengenai apa yang berubah, dan jika ada perubahan maka perubahan itu sebaiknya direstui secara model dan feasible. Perubahan dapat diklasifikasikan sebagai perilaku, struktural, dan prosedural. 7. Melakukan aksi untuk memperbaiki situasi bermasalah Saat akomodasi ditemukan, maka aksi-aksi dapat dilakukan untuk memperbaiki situasi yang bermasalah. Universitas Indonesia


27

Dalam menjalakan metodologi ini kita dapat menggunakan 4 alat bantu sebagai berikut: 1. Rich Picture Rich Picture adalah penggambaran nyata yang memungkinkan bermacammacam fitur situasi bermasalah sebagaimana itu dirasakan. Rich picture dapat membantu dalam kreativitas, menunjukan hubungan satu sama lain dalam situasi bermasalah, memudahkan dalam berbagi ide antara mereka yang terlibat, katalis dalam diskusi, dan sebagai bantuan mengingat.

Gambar 2.7 Rich Picture Sumber: Jackson (2003)

2. Root Definition Root definition adalah pernyataan ringkas mengenai apakah sistem itu dalam bentuk yang paling fundamental. Karena root definition adalah model dasar dari aktivitas manusia yang memiliki tujuan, maka root definition memiliki proses transformasi utama ( T ) yang mengubah beberapa masukan menjadi Universitas Indonesia


28

sesuatu yang baru atau keadaan yang baru sebagai keluaran. Root definition juga harus menjelaskan Weltanschauung ( W ) yang menjadikan transformasi memiliki arti secara konteks. Selain kedua elemen tersebut, ada beberapa elemen lain yang diringkas menjadi CATWOE dengan penjelasan sebagai berikut: a. C (Customers): pihak yang mendapatkan keuntungan atau mengalami kerugian dari proses transformasi. b. A (Actors): pihak yang melakukan proses transformasi. c. T (Transformation): pengubahan masukan menjadi keluaran. d. W (Word view): pandangan dunia luar yang membuat transformasi memiliki arti. e. O (Owners): pihak yang dapat menghentikan proses transformasi. f. E (Environtmental constraints): elemen di luar sistem yang dimiliki atau diberikan. 3. Model konseptual Model konseptual bukanlah berasal dari dunia nyata, tetapi model yang dibuat dari konstruksi dari holon yang memiliki tujuan dengan tujuan untuk memfasilitasi debat terstruktur. Model konseptual dibuat dengan memikirkan dan menuliskan aktivitas minimum yang dirasa dibutuhkan untuk menjalankan proses transformasi. Holon ini adalah aktivitas manusia, sehingga berupa kalimat kerja yang mendefinisikan aktivitas nyata yang dapat dilakukan manusia. Aktivitas ini disusun secara logis dalam hal interaksi antar aktivitas dan menunjukan ketergantungan satu sama lain. Berikut adalah contoh model konseptual:



29

Gambar 2.8 Model Konseptual Sumber: Jackson (2003)

4. Perbandingan Untuk membandingkan model konseptual dengan apa yang dilihat ada saat ini dapat menggunakan 4 cara: a. Diskusi informal dari perbedaan utama antara model konseptual dengan keadaan saat ini. b. Pertanyaan formal dari perbedaan-perbedaan utama yang melibatkan pengisian matriks yang menyatakan tiap aktivitas ada atau tidak ada, bagaimana dilakukan, bagaimana justifikasinya, dan komentar-komentar. c. Menuliskan skenario berdasarkan pengoperasian aktivitas manusia pada sistem baik di pikiran atau di kertas untuk melihat bagaimana sistem diharapkan di masa depan. Universitas Indonesia


30

d. Mencoba memodelkan model ke dalam dunia nyata menggunakan struktur yang ada di model konseptual untuk menunjukan perbedaan signifikan yang dapat mengundang diskusi. 2.6

Pengumpulan data kualitatif

Menurut Yin (2011), data adalah suatu kumpulan informasi yang terorganisir, yang biasanya dihasilkan dari pengalaman, observasi, percobaan, dan lain-lain yang dapat berisi angka-angka, kata-kata, gambar, yang biasanya merupakan ukuran atau observasi dari suatu set variabel. Dalam pengumpulan data-data terkait dengan penelitian kualitatif terdapat empat jenis aktivitas sebagai berikut: 1. Wawancara Sekaran (2003), membagi wawancara ke dalam 2 jenis yaitu: wawancara tidak tersutruktur dan terstruktur. Wawancara tidak terstruktur sebagaimana namanya maka pewawancara tidak membuat urutan pertanyaan terencana yang akan ditanyakan kepada responden. Tujuannya adalah membawa isu ke permukaan dan kemudian peneliti baru menentukan variabel yang perlu untuk diteliti lebih dalam. Sedangkan pada wawancara terstruktur pewawancara memiliki sebuah daftar pertanyaan yang sudah ditentukan sebelumnya. Biasanya wawancara terstruktur dilakukan ketika sudah diketahui informasi apa yang diperlukan. Peneliti boleh saja menanyakan beberapa pertanyaan yang relevan terkait dengan jawaban yang diberikan oleh responden. Berikut adalah teknik wawancara yang dijelaskan oleh Sekaran: a. Funneling: pada awal dari wawancara tidak terstruktur dianjurkan untuk menanyakan pertanyaan terbuka terkait dengan ide atau impresi dari situasi yang ada, misalnya “Bagaimana perasaan anda berkerja dalam organisasi ini?”. Dari pertanyaan yang luas ini baru dikerucutkan ke hal yang lebih detail. b. Pertanyaan yang tidak bias: gunakan pertanyaan yang dapat menjamin sedikit bias dalam meresponnya. Jangan ada muatan persepsi pewawancara yang mengarahkan responden. Universitas Indonesia


31

c. Mengklarifikasi isu: untuk memastikan pewawancara mengerti isu yang ingin disampaikan oleh responden maka dianjurkan untuk menyatakan ulang informasi penting yang diberikan oleh responden. d. Membantu responden untuk berpikir memecahkan masalah: jika responden tidak mampu menyatakan persepsinya dalam kata-kata maka peneliti sebaiknya menanyakan pertanyaan dalam bentuk yang lebih sederhana atau memfrasekannya. e. Membuat catatan: saat melakukan wawancara peneliti sebaiknya membuat catatan tertulis saat wawancara berlangsung atau sesegera mungkin setelah wawancara selesai. Pewawancara tidak seharusnya mengandalkan ingatannya saja. 2. Observasi Banyak hal yang dapat diobservasi tergantung dari topik penelitian kualitatif yang dilakukan. Berikut adalah kategori yang relevan untuk diobservasi: a. Karakteristik dari individu, termasuk cara berpakaian, bahasa tubuh, dan perilaku non-verbal. b. Interaksi antara individu. c. Aksi yang dilakukan, baik manusia maupun mesin. d. Fisik dari sekeliling, termasuk visual dan audio. Hal yang membuat observasi sulit adalah peneliti tidak dapat dengan mudah merekam observasi sebagaimana mesin. Penelitian kualitatif lebih mengarah kepada konsep yang lebih luas mengenai perilaku sosial orang, seperti rutinitas, ritual, dan interaksi dengan orang lain. 3. Collecting dan Examining Collecting merujuk kepada aktivitas mengkompilasi atau mengakumulasi objek-objek seperti dokumen, artifak, dan catatan-catatan yang terkait dengan topik penelitian. Collecting dapat menghabiskan banyak waktu dan ada dua cara untuk mendapatkan collecting yang produktif. Pertama, pikirkan ide Universitas Indonesia


32

objek apa saja yang akan dikoleksi. Kemudian pikirkan tingkat kesulitan dalam mengakses dan mengambil objek-objek tersebut. Lalu putuskan apakah mengambil semua atau sampel saja. Jika sampel sudah dirasa mencukupi maka definisikan sampel dengan hati-hati agar tidak menimbulkan bias. Kedua, setelah melakukan koleksi ringkas diawal segera tinjau hasil datanya dan pertimbangkan bagaimana materi yang sudah dikumpulkan itu sudah mencukupi studi. 4. Feeling Kata feeling merepresentasikan hasil dari sense of touch peneliti. Feeling adalah suatu sifat variatif yang ada pada peneliti yang berpotensi penting dalam penelitian. Feeling atau perasaan dapat merepresentasikan data eksplisit mengenai lingkungan seperti hangat/dingin, berisik/sunyi. Feeling juga

dapat

merepresentasikan

data

mengenai

orang,

misalnya

tergantung/menentang, dekat atau tidak akrab. 2.7

Focus Group Discussion

Menurut Bader & Rossi (2002), Focus Group adalah suatu wawancara berkelompok jenis khsus yang terstruktur untuk mengumpulkan opini dan pengetahuan detil tentang suatu topik tertentu dari peserta yang terpilih. Agenda yang dilakukan meliputi: 1. Perkenalan Perkenalkan diri anda secara ringkas. Perkenalkan juga notulen dan minta peserta untuk juga memperkenalkan diri jika diperlukan. Buat peserta menjadi relaks, anda juga bisa membuat anekdot untuk mencairkan suasana. Deskripsikan tujuan umum dari sesi-sesi yang ada. Identifikasi tujuan penggunaan data focus group, jaga anonimitas peserta dalam rekaman, analisis, dan laporan hasil. Jelaskan kapan dan dalam format apa intisari yang diterima peserta. 2. Periode pemanasan



33

Diskusikan isu umum yang sudah diidentifikasi dalam suatu pernyataan. Masukan juga informasi latar belakang dari organisasi yang relevan dengan topik untuk membantu peserta mulai berpikir sebelum mengajukan pertanyaan-pertanyaan yang lebih spesifik. 3. Opsi tertulis Terkadang ada baiknya juga untuk meminta peserta menuliskan pengalaman personal mereka terkait dengan topik yang bahas. Ini membuat peserta fokus pada topik dan mengekspresikan perasaan mereka tentang topik ini. Gunakan nomor kartu, jangan gunakan nama dan kumpulkan kartu tersebut. Informasi ini menjadi suplemen data dari diskusi. 4. Periode pertanyaan Tanyakan dua atau tiga pertanyaan dalam urutan prioritas kepentingan. Tentukan dari awal waktu diskusi yang memadai untuk setiap pertanyaan. Untuk topik yang sensitif berikan waktu yang lebih lama. Biasanya sesi normal berjalan selama 1-2 jam, dengan 3-4 pertanyaan luas dan 2-3 pertanyaan susulan untuk tiap pertanyaan awal. Untuk tiap isu mulailah dari pertanyaan umum lalu bergerak ke pertanyaan detil. Gunakan pertanyaan terbuka. 5. Intisari Pada akhir sesi, jelaskan intisari secara ringkas pada poin-poin utama dari sesi-sesi diskusi. Yakinkan bahwa tiap komentar sudah dipahami dengan benar dan berikan peserta kesempatan untuk membuat pernyataan akhir. Orang-orang biasanya memiliki pemikiran yang berharga dan pernyataan akhir memberikan kesempatan untuk berbagi pemikiran tersebut. Berikut adalah contoh agenda Focus Group:



34

Gambar 2.9 Agenda Focus Group The Winner’s Ink Sumber: Bader & Rossi (2002)

2.8

Benchmarking

Menurut Wireman (2003), benchmarking adalah proses mengukur dan meningkatkan praktek bisnis terhadap perusahaan-perusahaan yang diidentifikasi sebagai terbaik ditaraf dunia. Benchmarking memberikan pemahaman yang dalam



35

pada proses dan keahlian yang menciptakan performa unggul. Ada beberapa jenis benchmarking yang dapat digunakan dalam melakukan benchmarking proyek: 1. Benchmarking internal: benchmarking internal melibatkan departemen atau proses didalam organisasi. Benchmarking dengan jenis ini memiliki kelebihan dalam pengumpulan dan perbandingan data yang mudah. Kelemahannya dari benchmarking ini adalah biasanya tidak menghasilkan terobosan yang besar dalam peningkatan performa. 2. Benchmarking industri sejenis: benchmarking ini menggunakan rekanan luar yang memiliki industri atau proses yang mirip. Benchmarking ini mungkin sulit untuk dibeberapa industri tertentu tetapi banyak perusahaan terbuka untuk berbagi mengenai informasi yang bukan hak intelektual. Benchmarking ini berfokus pada pengukuran organisasi. 3. Best Practice: benchmarking ini berfokus pada menemukan proses yang terbaik dan tidak diragukan lagi. Benchmarking ini lintas sektor industri dan lokasi geografis dimana memberikan kesempatan munculnya strategi terobosan. Organisasi mempelajari proses binis di luar industrinya, beradaptasi atau mengadopsi proses bisnis yang superior, dan membuat lompatan performa terhadap para kompetitornya. 2.9

Standard Operating Procedure

Menurut Prasanna (2013), Standard Operating Procedure (SOP) adalah aktivitas rutin atau berulang yang terdokumentasi untuk membentuk serangkaian instruksi tertulis, seperti manual yang memberikan seseorang atau karyawan untuk melakukan suatu pekerjaan dengan benar yang memfasilitasi produk atau layanan akhir yang berkualitas dan berintegritas. Menurut Federal Emergency Management Agency (1999), SOP adalah arahan secara organisasi yang membentuk suatu rangkaian aksi. Jadi SOP adalah serangkaian instruksi yang terdokumentasi untuk melakukan aktivitas rutin yang diakui oleh organisasi agar aktivitas yang dilakukan efisien dan berkualitas. Menurut penulis, Simbol yang sedikit ini bisa saja tidak mencukupi kebutuhan dari Standard Operating Procedure yang akan dibangun tetapi ini justru menjadi Universitas Indonesia


36

tantangan bagi pembuat Standard Operating Procedure agar dapat membuat procedure yang sesederhana mungkin sehingga mudah dipahami oleh yang akan mengerjakan procedure tersebut. Dari tinjauan dokumen kebijakan perusahaan (Lampiran 9), PT Toyota Astra Financial Services memiliki format SOP yang berisi: 1. Tujuan dari ada SOP tersebut. 2. Ruang lingkup dari SOP yang dibuat. 3. Definisi dari kata-kata asing yang digunakan dalam SOP. 4. Dasar kebijakan melandasi SOP. 5. Dokumen yang dihasilkan dari SOP. 6. Diagram prosedur SOP. Diagram terdiri dari kolom proses, dokumen yang dihasilkan, dan keterangan dari setiap langkah proses. Proses yang muncul juga memiliki keterangan peran/role yang melakukan proses tersebut. 2.10 Penelitian Sebelumnya Penulis melakukan penelusuran penelitian sebelumnya mengenai manajemen layanan IT Help desk. 2.10.1 Towards an Improved IT Service Desk System and Processes: A Case Study Menurut Marko Jäntti (2012), Service desk bertangung jawab untuk melaksanakan manajemen insiden dan proses pemenuhan permintaan. Tujuan utama dari service desk adalah untuk menormalisasi kembali layanan kepada pengguna secepat mungkin. Tugas dari agen IT Service Desk adalah untuk mencatat, melakukan klasifikasi, melakukan diagnosa, dan menyelesaikan kasus service desk dari pelanggan dan pengguna. Kasus yang dimaksud dapat berupa insiden berupa kegagalan perangkat lunak dan perangkat keras, permintaan layanan seperti melakukan pengesetan ulang kata sandi, keluhan maupun umpan balik. Engineer dari service desk juga bertanggung jawab dalam mengidentifikasi permintaan



37

perubahan fitur aplikasi ataupun infrastruktur TI yang disebut Request for Change (RFC) maupun mengidentifikasi masalah. Layanan sistem informasi dan teknologi diklasifikasikan menjadi 4 kategori: 1. Layanan Aplikasi: layanan yang diberikan oleh aplikasi perangkat lunak. 2. Layanan Operasional: layanan dalam memelihara lingkup TI seperti instalasi perangkat keras maupun perangkat lunak, manajemen perubahan, pemecahan masalah, dan menjalankan pusat data. 3. Layanan Value-Enabling: layanan yang meningkatkan nilai/value dari aset informasi seperti konsultasi, perancangan sistem, dan lain-lain. 4. Layanan Infrastruktur: layanan yang berfokus pada kapabilitas teknis dari infrastruktur TI seperti kapasitas dan keamanan aset TI. Ada banyak cara meningkatkan pelayanan IT Service desk atau helpdesk adalah melalui penggunaan based practice dari ITIL. Manajemen layanan pada ITIL versi 2 terdiri dari dua bagian yaitu Service Delivery dan Service Support. Sedangkan ITIL versi 3 menekankan pada pemikiran daur hidup layanan yang dituangkan ke dalam 5 buku inti: perecanaan layanan, perancangan layanan, transisi layanan, operasi layanan, dan peningkatan layanan berkelanjutan. Menurut Jantti (2012) Service desk merupakan bagian dari fase Operasi Layanan pada daur hidup layanan. Ada beberapa faktor yang menghambat efektivitas proses peningkatan service desk. 1. Perusahaan menyewa ITIL konsultan eksternal yang memberikan pelatihan kepada para karyawan dimana para konsultan ini mengetahui konsep kerangka kerja ITIL dan konsep manajemen layanan TI tetapi memiliki pengetahuan terbatas mengenai konsep bisnis, metode, aplikasi, layanan, dan struktur service desk perusahaan saat ini. 2. Aplikasi/Tools manajemen layanan TI yang kurang memadai atau terlalu kompleks mungkin menghambat inisiatif perbaikan proses. 3. Kurangnya budaya proses dan berfikir proses yang merupakan fenomena umum di kalangan perusahaan TI. Universitas Indonesia


38

Tantangan pada peningkatan service desk lebih dari peninjauan proses saja, tetapi juga aspek subjektif “manusia” seperti motivasi staff dan customer experience penting untuk menghasilkan nilai/value bisnis. Pada jurnalnya Marko Jäntti (2012) menyusun 10 langkah dari studi literaturnya dan interpertasi dalam mengevaluasi langkah-langkah ITSM menggnakan kerangka kerja ITIL dengan fokus pada fase Operasi Layanan. 1. Ketahui sumber daya anda Memeriksa sumber daya yang dimiliki untuk mengetahui kapabilitas yang dapat di-deliver dan yang tidak dapat di-deliver. Implementasikan cara-cara untuk meningkatkan keahlian, perlengkapan, dan kontak. IT Service Management (ITSM) mengetahui sumber daya adalah penting. Organisasi bertanggung jawab atas kapabilitas dalam men-deliver layanan. Gabungan dari sumber daya dan kapabilitas ini yang disebut asset layanan. Sumber daya dikonsumsi oleh proses delivery layanan dan kapabilitas menunjukan kemampuan dalam mengelola sumber daya. Tanpa mengetahui sumber daya dan kapabilitas maka tidak ada dasar dalam mendefinisikan nilai layanan. 2. Ketahui pelanggan anda Mengidentifikasi pelanggan baik yang merupakan pengguna layanan anda maupun yang tidak dan buat urutan prioritas. Pada disiplin ITSM, pelanggan dan pengguna adalah stakeholder yang penting pada manajemen layanan. Pelanggan merepresentasikan individu atau grup yang membeli layanan dimana didalamnya ada Service Level Agreement (SLA) dan pengguna yang menggunakan layanan anda pada tingkatan operasional dan berbeda dengan pelanggan. 3. Luncurkan layanan anda Luncurkan beberapa layanan yang memenuhi kebutuhan pelanggan terbanyak dan dorong tiap pelanggan yang merasa layanan belum mencukupi untuk kembali melihat service statement sebagai dasar negosiasi Service Level Agreement khusus dengan mereka. Pada ITSM, meluncurkan layanan merujuk kepada fase transisi layanan dalam daur hidup layanan. Tetapi Universitas Indonesia


39

perencanaan atas layanan yang akan diluncurkan harus sudah diinisiasi sewaktu fase perancangan layanan. Informasi atas layanan yang diluncurkan harus ada pada katalog layanan. Bisa saja ada 2 jenis katalog layanan yaitu: level bisnis (dirancang untuk pelanggan) dan level teknis (dirancang untuk tim production). 4. Kelola workflow support Pengelolaan workflow membutuhkan penetapan manajemen workflow yang efektif pada departemen support. Penetapan ini mencakup manajemen panggilan telepon, prioritas pertanyaan, alokasi pekerjaan, eskalasi masalah, dan motivasi pegawai. 5. Memastikan teknik penyelesaian masalah Tidak cukup hanya menyelesaikan masalah dari pengguna saja, perlu dipastikan juga metode yang dipakai dalam penyelesaian masalah memastikan kepuasan pelanggan. Pada ITSM, ada prosedur penutupan masalah yang terpisah antara masalah dan insiden. Penutupan suatu masalah berimplikasi menutup beberapa insiden dan petugas manajemen masalah bertanggung jawab dalam mengelola error yang sudah diketahui. 6. Reporting status beban kerja secara instan Buat reporting rutin untuk memberikan potret dari beban kerja saat ini lalu disimpan secara rutin juga. Ini membuat kita mampu membuat keputusan bagaimana kita sebaiknya mengelola sumber daya kita. Aplikasi ITSM dewasa ini dapat memberikan laporan secara real time dan sumber daya yang telah dipergunakan pada penutupan insiden atau masalah. 7. Proaktif Temukan dan implementasikan penanganan workload secara proaktif. Kita sebaiknya menghidari helpdesk dicontrol oleh workload. Manajemen layanan pada ITSM seharusnya fokus pada tindakan proaktif, bukan reaktif. Aksi proaktif tergambar dalam proses manajemen masalah (peninjauan masalah-



40

masalah utama, analisis tren, pendifinisian aksi preventif) dan proses peningkatan layanan yang berkelanjutan. 8. Kontak rutin dengan customer Jalin komunikasi dengan customer melalui surel/email, workshop, berbagi pengetahuan, dan juga kontak personal. Pada ITSM komunikasi memegang peranan sangat penting. Service desk bertangung jawab mengkomunikasikan resolusi insiden, perkembangan resolusi, dan memberi informasi dari layanan baru. Komunikasi juga bisa dilakukan dalam peninjauan layanan, Service Level Agreement, dan pendefinisian tingkatan layanan. 9. Lakukan survey Lakukan survey terhadap pelanggan untuk mendapatkan sudut pandang customer dan bagaimana layanan di-deliver. Informasi ini dapat dipergunakan untuk meningkatkan layanan support kepada pelanggan. 10. Ulangi langkah-langkah diatas tiap 4 sampai 6 bulan Repetisi langkah-langkah diatas sebagai kegiatan continous improvement pada helpdesk. Pada ITSM peningkatan layanan berkelanjutan adalah salah satu fase dalam daur hidup layanan. Penelitian yang dilakukan Jantti dilakukan di administrasi pajak Finlandia. Tujuan penelitan tersebut adalah mencari tahu bagaimana operasi service desk sebagai penyedia layanan TI dapat ditingkatkan dengan menerapkan best practice ITSM. Administrasi pajak Finlandia terdiri 12 unit organisasi dengan 5300 karyawan di tahun 2011. Sedangkan pegawai yang berkerja sebagai IT support untuk pengguna sebanyak 70 orang. Data dikumpulkan dari dokumentasi kasus organisasi (panduan manual, katalog layanan, dan lain-lain), arsip-arsip (skema klasifikasi layanan, catatan insiden dan masalah), wawancara, diskusi, obervasi, dan artefak fisik (aplikasi). Assesmen dilakukan berdasarkan best practice dari ITIL versi 2 dan versi 3 dan ISO 20000-I untuk manajemen insiden. Dari assesmen tersebut didapatkan: 1. Banyak proses dituliskan dalam bentuk diagram aktivitas. Universitas Indonesia


41

2. Organisasi telah membuat deskripsi proses manajemen insiden. 3. Organisasi telah mempunyai fokus yang kuat pada peningkatan layanan yang berkelanjutan. 4. Dukungan dan komitmen dari pihak manajemen untuk meningkatkan manajemen layanan TI yang sangat terlihat pada organisasi. 5. Pilihan aplikasi service desk yang mendukung dan prinsip-prinsip ITSM dan tim administrasi aplikasi yang terampil dan termotivasi. 6. Karyawan Service Desk yang sangat tertarik dengan pelatihan ITSM. Berikut adalah tantangan yang muncul dan saran untuk peningkatan baik dari sisi alat/tools dan proses: 1. Butuh klarifikasi atas klasifikasi dari permintaan support. Saran dari segi tools adalah memperjelas pilihan dari inputan alasan dalam melakukan kontak permintaan. 2. Pelanggan tidak dapat melakukan klasifikasi permintaan support dengan benar. Saran dari segi alat adalah membuang pilihan klasifikasi dari pelanggan dan menyederhanakan masukan dalam permintaan support. 3. Sulit untuk melakukan identifikasi insiden yang berulang dari sistem service desk. Saran dari segi alat adalah berikan tanda/flag insiden berulang pada sistem dan buat fitur kasus berelasi untuk menggabungkan insiden. Buat catatan masalah berdasarkan insiden berulang. 4. Antarmuka antara manajemen insiden dan manajemen masalah tidak berkerja karena pengguna tidak ada mengetahui perbedaan antara insiden dan masalah. Saran dari segi proses adalah memberikan pelatihan kepada karyawan dan membuat panduan sederhana. 5. Pegawai service desk mencatat beberapa kasus dalam satu insiden. Saran dari segi proses adalah memberikan pelatihan kepada pegawai untuk mencatat satu insiden satu isu.



42

6. Ide peningkatan tidak dicatat secara sistematis ke dalam sistem service desk. Saran dari segi proses adalah ide peningkatan seharusnya dikirim ke tim peningkatan layanan berkelanjutan atau tim manajemen perubahan. 7. Kurangnya Configuration Management Database (CMDB) yang formal. Saran dari segi alat dan proses adalah membuat proses manajemen konfigurasi yang bertanggung jawab memperbaharui, memelihara, dan mengatur CMDB. 2.10.2 Effective Implementation of Problem Management in ITIL Service Management Menurut Kannamani (2013), ada 2 disiplin umum dalam Manajemen Layanan ITIL yaitu Service Support dan Service Delivery. Dimana pada Service Support terdiri dari Service Desk, Manajemen insiden, Manajemen masalah, Manajemen konfigurasi, Manajemen perubahan, dan Manajemen Rilis. Masalah adalah kondisi yang sudah teridentifikasi dari kemunculan beberapa insiden dengan gejala yang sama, atau bersalah dari satu insiden besar dimana mengindikasikan suatu error yang mana belum diketahui penyebabnya. Tujuan utama dari manajemen masalah adalah untuk meminimalisir dampak merugikan dari insiden dan masalah terhadap bisnis yang disebabkan oleh kesalahan didalam infrastruktur TI dan juga mencegah terjadinya kembali insiden yang berelasi dengan kesalahan tersebut. Sedangkan manajemen insiden adalah basis untuk mendefinisikan masalah dan informasi dan menyediakan informasi bagi manajemen masalah untuk melakukan pencocokan insiden. Fokus dari manajemen insiden adalah pada resolusi insiden yang cepat sedangkan manajemen masalah berfokus untuk menganalisis akar penyebab terjadinya insiden. Adanya manajemen masalah memberikan keuntungan berupa: 1. Peningkatan kualitas layanan TI 2. Pengurangan jumlah insiden 3. Memberikan solusi permanen



43

4. Meningkatkan pengetahuan organisasi melalui kontribusi data mengenai error yang telah diketahui kepada service desk. Adanya manajemen masalah menghasilkan hal-hal berikut: 1. Data mengenai error yang telah diketahui dan resolusi yang dapat dilakukan. Data ini disimpan dalam suatu Configuration Management Database (CMDB) yang memberikan informasi kepada service desk atau proses-proses ITSM. 2. Request

for

Change

(RFC),

yaitu

permintaan

perubahan

fitur

aplikasi/layanan. RFC mendeskripsikan perubahan yang perlu dilakukan untuk mengatasi error yang sudah diketahui. Manajemen tidak menangani persetujuan atau pelaksanaan perubahan. RFC ini dilanjutkan oleh proses ITSM yang lain yaitu manajemen perubahan. 3. Perubahan data dalam CMDB. Informasi mengenai error yang sudah diketahui dan perubahan Configurable Item (CI) dilanjutkan ke proses manajemen konfigurasi, proses ITSM yang menangani perubahan CMDB. Pendekatan yang dipergunakan manajemen masalah ada 2 jenis yaitu: 1. Manajemen masalah reaktif Manajemen masalah reaktif mencari solusi dari gejala masalah. Pendekatan reaktif merespon laporan insiden yang sudah terjadi. Dimana didalamnya ada 2 aktivitas: a. Aktivitas kendali masalah 

Identifikasi dan pencatatan: manajemen masalah menerima laporan insiden dari manajemen insiden dan service desk. Kemudian tim manajemen masalah menganalisis informasi tersebut dan mencari kemiripan gejala dari insiden tersebut dengan insiden lain yang sudah dicatat sebelumnya. Jika tidak dapat ditemui maka insiden dicatat sebagai masalah baru.



44



Klasifikasi: Mengidentifikasi tingkat kepentingan dari masalah baru dan menentukan sumber daya yang menanganinya. Masalah dapat diklasifikasi menjadi beberapa kategori sehingga dapat ditugaskan ke personil terkait. Masalah juga diklasifikasi berdasarkan urutan prioritas. Masalah dengan prioritas lebih tinggi didahulukan dari pada masalah dengan prioritas lebih rendah.

b. Penyidikan dan diagnosa Tim dari manajemen masalah mencari akar penyebab dari masalah. Jika penyebab ditemukan maka manajemen masalah merekomendasikan solusi atau perbaikan sementara. Dalam sistem manajemen layanan yang terotomasi, statu masalah kemudian berubah menjadi error yang diketahui. 2. Manajemen masalah proaktif Manajemen masalah proaktif dipicu oleh komponen berikut: a. Tren insiden Proses ini memeriksa laporan masalah dan insiden untuk mengetahui tipe masalah apa yang sering terjadi. Analisis trend dari masalah dan insiden yang ada dapat menunjukan kemiripan masalah yang mungkin muncul ditempat lain dalam infrastruktur. Kegagalan yang berulang menunjukan bahwa masalah atau insiden tersebut belum ditangani secara tuntas dan cenderung akan terus muncul. b. Aksi preventif Proses ini menggunakan teknik yang sama pada manajemen masalah reaktif untuk menentukan beberapa masalah potensial dengan dampak terhadap bisnis yang besar. Aksi preventif melibatkan pembuatan RFC, memberikan pelatihan kepada pengguna dan tim service desk, atau memberikan rekomendasi perubahan prosedur didalam departemen TI. Berisi aktivitas memeriksa trend insiden dan melakukan aksi pencegahan.



45

Apa yang terjadi di industri pada skenario nyata suatu perusahaan TI kelas dunia berbeda dengan pembahasan diatas. Kannamani berinterasi dengan administrator sistem dan spesialis sistem yang memiliki pengalaman dalam bidang industri TI dengan pengetahuan ITIL dan menemukan bahwa beberapa catatan masalah ditutup tanpa adanya ticketing. Selain itu ditemukan juga ticket masalah yang ditutup tanpa melakukan identifikasi penyebabnya ataupun melakukan penutupan ticket tanpa melakukan mapping terhadap catatan perubahan. Kannamani juga menunjukan diagram bahwa hanya kurang dari 50% ticket masalah yang ditutup dengan adanya catatan perubahan. Keuntungan dengan menghubungkan setiap masalah dengan catatan perubahan adalah sebagai berikut: 1. Manajemen Catatan: jika resolusi dilakukan melalui proses manajemen perubahan maka itu tercatat pada aplikasi bahwa resolusi ini sudah melalui tim yang mana saja dan melalui persetujuan siapa saja. Sehingga segala sesuatunya tercatat. 2. Manajemen Audit: dengan manajemen perubahan memeliki semua informasi yang relevan terkait isu, detil penyidikan, resolusi, dan informasi persetujuan; hal ini sangat membantu saat dilakukan pemeriksaan/audit sekaligus menjaga sertifikasi ISO perusahaan. 3. Resolusi Sempurna: dengan menggunakan metode tersebut tidak ada masalah yang tercatat dilakukan penutupan tanpa adanya resolusi. Karena catatan perubahan diwajibkan untuk semua masalah. 4. Roll Back: saat melakukan implementasi, resolusi diharapkan memiliki tingkat kesuksesan 100%, tetapi dalam beberapa kasus kemungkinan gagal juga ada. Dengan adanya informasi yang lengkap pada catatan perubahan maka sangat mudah untuk melakukan roll back dari perubahan yang baru saja dilakukan.



46

2.11 Tinjauan Metodologi penyusunan manajemen operasi layanan TI ITIL dapat menjadi acuan kerangka kerja dalam penyusunan manajemen layanan TI pada IT Helpdesk. Tetapi tidak selalu implementasinya berjalan mulus. Berikut perbandingan implementasi ITIL pada penelitian sebelumnya. Tabel 2.1 Perbandingan implementasi ITIL Concise

Compare

Contrast

Critize

Jäntti Kontribusi yang dibuat untuk layanan service desk dilakukan eksplorasi pada ranah aplikasi/tools, metode swalayan, struktur fungsi service desk, tantangan service desk, dan solusi dari tantangan yang muncul.

Hasil dari penelitian yang dilakukan memberikan rekomendasi tools, metode, struktur fungsi, dan rekomendasi implementasi kepada organisasi. Penelitian dilakukan pada ruang lingkup pemerintahan, yaitu administrasi perpajakan pemerintah Finlandia. Penelitian dilakukan berdasarkan proyek KISMET yang didanai oleh pemerintah finlandia yaitu TEKES. Sehingga implementasi ITIL sangat didukung dari pihak internal service desk dan pemerintah. Sedangkan implementasi ITIL pada penelitian yang akan dilakukan belum tentu mendapatkan response positif dari tim service desk.

Kannamani Implemetasi ITIL dapat membangu suatu manajemen masalah yang reaktif dan proaktif. Konsistensi dalam mengikuti proses juga harus menjadi perhatian. Memetakan antara insiden dengan masalah akan memberikan manfaat dimasa depan. Memberikan penjabaran manfaat dari implementasi kerangka kerja ITIL dan pendekatan manajemen masalah proaktif dan reaktif. Penelitian dilakukan pada lingkup perusahaan TI kelas dunia. Dikatakan bahwa beberapa perusahaan TI kelas dunia tidak konsisten dalam mengikuti proses manajemen masalah. Tetapi pada penelitian ini tidak dijelaskan penyebab mengapa terjadi hal tersebut.



47 Tabel 2.1 Perbandingan implementasi ITIL (Sambungan) Penelitian Kannamani dan Hubungan Penelitian Jantii dan penelitian penelitian yang akan yang akan dilakukan keduannya dengan dilakukan keduannya penelitian menggunakan best practice ITIL. menggunakan best practice Implementasi ITIL Jantti di ini perpajakan Finlandia memberikan ITIL dan keduanya dilakukan pada perusahaan swasta. beberapa hal yang menjadi Penelitian Kannamani tantangan dalam menjelaskan pendekatan mengimplementasikan ITIL ke manajemen masalah reaktif dalam service desk. Penulis akan dan proaktif. Penulis akan menggunakan tantang dalam implementasi ITIL ini sebagai hal menggunakan pendekatan yang dilakukan Kannamani yang harus dicek apakah usulan perubahan proses pada manajemen sebagai masukan prosesproses yang akan diusulkan operasi layanan sudah kepada organisasi. mengakomodasi tantangan tersebut. Impementasi pada lingkup pemerintahan cenderung didukung dari pihak internal yang mungkin saja dijalankan dengan tingkat kepatuhan yang tinggi. Sedangkan pada ruang lingkup perusahaan, proses yang sudah diimplementasi dapat saja diabaikan. Manajemen problem sebaiknya tidak hanya reaktif tetapi juga proaktif sehingga sumber daya organisasi tidak selalu oleh insiden atau masalah yang masuk dan berujung ke kontrol sumber daya yang lebih reaktif. ITIL sebagai best practice dari manajemen layanan TI memberikan banyak manfaat secara kualitas layanan dan manajemen masalah. 2.12 Theoretical Framework Implementasi ITIL memberikan banyak best practice, menurut Jantti pada penelitiannya bahwa adanya Service Desk menunjukan bahwa daur hidup layanan sudah memasuki fase operasi layanan pada kerangka kerja ITIL v3. Best practice dari service operation pada ITIL v3 dapat diambil sebagai masukan dalam menyusun manajemen operasional layanan IT Helpdesk. Penelitian-penelitan pada landasan teori itu memberikan kita informasi tantangan dalam implementasi proses-proses ITIL service desk di organisasi pemerintah maupun perusahaan. 10 langkah pengelolaan service desk dari penelitian jantti dapat kita ambil sebagai masukan dalam implementasikan manajemen operasi layanan ITIL v3 di Toyota Astra Finance. Pada penelitian Kannamani diberikan Universitas Indonesia


48

penjelasan mengenai implementasi manajemen masalah yang reaktif dan proaktif menggunakan ITIL. Dengan memasukan manajemen reaktif dan proaktif diharapkan efisiensi dari IT Helpdesk dapat meningkat dan sumber daya IT Helpdesk yang terbatas ini dapat lebih optimal dimasa yang akan datang. Untuk itu manajemen reaktif dan proaktif ini dapat diambil sebagai masukan dalam implementasikan manajemen operasi layanan ITIL v3 di Toyota Astra Finance. Seperti apa yang dikatakan pada penelitian yang dilakukan oleh Jantti bahwa proses yang kurang memadai atau terlalu kompleks dari ITIL dapat menghambat inisatif proses perbaikan. Untuk itu manajemen operasi layanan IT Helpdesk di Toyota Astra Finance juga harus memperhatikan budaya perusahaan dan kebijakan perusahaan. Kebijakan perusahaan diambil dari dokumen kebijakan perusahaan. Untuk budaya perusahaan diambil dari data-data wawancara. Perlu dilakukan juga benchmarking manajemen operasi layanan IT Helpdesk ditempat lain sebagai masukan dalam menyusun operasi layanan IT Helpdesk di Toyota Astra Finance. Memperhatikan hal-hal tersebut maka disusunlah kerangka berpikir sebagai berikut:



49

Gambar 2.10 Kerangka Berpikir Kerangka berpikir ini menjawab pertanyaan penelitian berkaitan dengan manajemen operasi layanan IT Helpdesk di Toyota Astra Finance.



BAB 3 METODOLOGI PENELITIAN

Pada bab ini penulis membahas mengenai alur metodologi penelitian dan penjelasan detail mengenai proses di dalamnya. Jenis penelitian yang dilakukan adalah action research dengan menggunakan metodologi SSM. Menurut Jackson (2003), SSM adalah metodologi yang memungkinkan intervensi pada suatu situasi bermasalah yang kurang sehat secara struktural dimana mempertahankan relasi sama pentingnya dengan mencari hasilnya, dan menjawab pertanyaan apa yang harus dilakukan sama pentingnya dalam menentukan bagaimana melakukannya. Sehingga menurut penulis SSM adalah metodologi yang sesuai untuk mengatasi permasalah yang terkait dengan proses-proses di dalam manajemen operasi layanan. Data yang diolah dapat berupa dokumen, hasil observasi, wawancara, dokumentasi perangkat lunak, dan/atau focus group discussion. 3.1

Alur Metodologi Penelitian

SSM memiliki 7 langkah tetapi hanya 5 langkah yang diambil pada alur metodologi penelitian. Langkah pertama pada SSM, yaitu situasi bermasalah, sudah tergambar pada perumusan masalah dan pertanyaan penelitian pada Bab I. Langkah terakhir pada SSM, yaitu melakukan aksi untuk memperbaiki situasi bermasalah dimasukan sebagai kesimpulan di Bab V. Diagram alur metodologi penelitian yang digunakan oleh penulis digambarkan pada gambar 3.1 dan gambar 3.2.

50



51

Gambar 3.11 Metodologi penelitian



52

Gambar 3.2 Metodologi penelitian 3.2

Detil Alur Metodologi Penelitian

Dalam

melaksanakan

penelitian

penulis

menggunakan

langkah-langkah

metodologi penelitian sebagai berikut: 1. Mengumpulkan data awal Langkah ini bertujuan untuk mendapatkan kondisi saat ini dan kondisi yang diharapkan oleh organisasi. Pengumpulan data dilakukan dengan metode observasi, wawancara, dan pengumpulan dokumen pendukung terkait yang dapat menjelaskan kondisi saat ini dan kondisi yang diharapkan. 2. Identifikasi masalah Tujuan langkah ini adalah mencari akar masalah yang terjadi di organisasi dan mendapatkan pertanyaan penelitian. Masukan dari langkah ini adalah keluaran dari langkah pertama yaitu kondisi saat ini dan kondisi yang Universitas Indonesia


53

diharapkan. Dari masukan tersebut didapatkan kesenjangan antara kondisi saat ini dan kondisi yang diharapkan sebagai masalah yang tampak dipermukaan. Menggunakan analisis fishbone masalah yang tampak dipermukaan digali akar-akar masalahnya dalam beberapa domain masalah. Akar masalah ini yang salah satunya dijadikan pertanyaan penelitian. Pertanyaan penelitian ini menjadi keluaran pada langkah ini. 3. Melakukan tinjauan pustaka Langkah ini bertujuan untuk mengetahui teori pendukung dan pengalaman penulis lainnya yang diambil dari tinjauan penelitian sebelumnya yang relevan. Masukan dari langkah ini adalah pertanyaan penelitian dari langkah kedua. Pada langkah ini penulis mencari teori-teori yang relevan. Keluaran dari langkah ini adalah kerangka berpikir yang menjadi landasan penulis dalam menyelesaikan permasalahan pada pertanyaan penelitian/research question. 4. Menyusun metodologi penelitian Tujuan langkah ini menghasilkan metodologi penelitian sebagai panduan urutan langkah melaksanakan penelitian. Langkah ini memiliki masukan berupa kerangka berpikir yang merupakan keluaran langkah ketiga. Keluaran dari langkah ini adalah metodologi penelitian. 5. Mengekspresikan situasi bermasalah Tujuan langkah ini adalah menangkap situasi yang bermasalah saat ini dengan membuat gambaran proses saat ini. Masukan langkah ini adalah metodologi penelitian dari langkah sebelumnya. Pada langkah ini dilakukan wawancara, observasi, dan mempelajari artefak yang berupa tools atau aplikasi yang digunakan oleh IT Helpdesk. Dari sumber-sumber tadi kemudian dibuat gambarannya yang merepresentasikan proses yang ada saat ini dalam bentuk rich picture. 6. Membuat root definition



54

Tujuan langkah ini adalah menghasilkan root definition dari proses layanan TI. Root definition ini merepresentasikan tujuan dari adanya sistim layanan TI. 7. Membuat model konseptual Model proses konseptual dari proses-proses yang akan ada di IT Helpdesk. Model proses konseptual dibangun dari hasil benchmarking dengan perusahaan lain dan best practice ITIL versi 3 pada fase operasi layanan. 8. Membandingkan model konseptual dengan dunia nyata Pada langkah ini disusun gap antara model konseptual dengan dunia nyata. Gap ini menjadi modal untuk melakukan FGD pada langkah berikutnya. 9. Menyusun perubahan Tujuan langkah ini adalah menyusun proses manajemen operasi layanan IT Helpdesk yang feasible di Toyota Astra Finance dan mendapatkan umpan balik. Pada langkah ini dianalisa materi mengenai challenges implementation ITIL, manajemen masalah reaktif dan proaktif, budaya perusahaan dan kebijakan perusahaan. Kemudian dilakukan Focus Group Discussion (FGD) dengan agen IT Helpdesk, supervisor IT Helpdesk, Analis Sistem, dan IT Development Department head yang membawahi IT Helpdesk. Dari FGD ini kemudian dihasilkan umpan balik atau proses layanan TI dan fitur tools penunjang yang sudah menjadi konsensus bersama. 10. Revisi Perubahan Langkah ini bertujuan menindak lanjuti umpan balik yang ada dari langkah sebelumnya. Pada langkah ini dilakukan revisi terhadap perubahanperubahan yang feasible berupa proses dan fitur aplikasi yang lebih diterima dengan organisasi sesuai dengan umpan balik dari FGD. 11. Menyusun kesimpulan dan saran Dalam merumuskan kesimpulan dan saran, penulis mengambil masukan berupa manajemen operasi layanan TI dan fitur aplikasi penunjang yang Universitas Indonesia


55

efektif bagi IT Helpdesk PT Toyota Astra Financial Services. Keluaran dari langkah ini adalah kesimpulan dan saran. 3.3

Metode Pengumpulan data

Pada penelitian ini data yang dibutuhkan adalah data kualitatif. Metode pengumpulan data kualitatif menggunaan beberapa metode. Berikut adalah metode yang dipergunakan. 1. Wawancara Wawancara dilakukan dengan pihak-pihak di dalam organisasi yang memegang peranan dalam layanan TI yang disediakan oleh PT Toyota Astra Financial Services. Pihak-pihak tersebut antara lain adalah agen IT Helpdesk, Supervisor IT Helpdesk, IT Developer/Analis Sistem, dan Kepala departemen IT Development. Tujuan utama dari pengumpulan data wawancara adalah mendapatkan model dunia nyata mengenai bagaimana proses yang ada pada operasi layanan IT Helpdesk saat ini. Pada ITIL proses operasi layanan mencakup 5 hal berikut: a. Manajemen event: proses memonitor semua kejadian/event b. Manajemen insiden: proses mengembalikan layanan secepatnya (solusi jangka pendek). c. Manajemen masalah : proses mencari akar masalah dan mengatasinya dan mendeteksi error/kesalahan kepada sub-proses terkait masalah tersebut. d. Pemenuhan permintaan : proses pemenuhan permintaan pengguna yang tidak termasuk sebagai insiden atau hambatan atau gangguan. e. Manajemen akses: proses pemberian dan pencabutan hak akses. Semua daftar pertanyaan merujuk kepada proses operasi layanan pada ITIL v3. Berikut adalah daftar pertanyaan yang ditanyakan:



56

Tabel 3.1 Tabel Pertanyaan Pertanyaan Permintaan yang masuk ke iCare itu apa saja?

Peran Supervisor dan Agen

Permintaan yang masuk ke iCare itu melalui apa saja?

Supervisor dan Agen

Bagaimana iCare mengelola permintaan yang masuk dari sejak permintaan diterima hingga informasi kembali kepada pengguna? Bagaimana iCare mengelola permintaan yang masuk yang terkait dengan operasional bisnis atau insiden? Bagaimana mengelola masalah dari suatu insiden? Bagaimana mengelola permintaan yang bukan terkait masalah? Bagaimana proses permintaan perubahan akses masuk? Apakah fungsi dan aktivitas dari iCare?

Supervisor dan Agen

Rujukan Manajemen event dan manajemen insiden pada ITIL v3 Service Operation Manajemen event dan manajemen insiden pada ITIL v3 Service Operation Manajemen insiden pada ITIL v3 Service Operation

Supervisor dan Agen

Manajemen insiden pada ITIL v3 Service Operation

Supervisor, Analis, dan Agen Supervisor, Analis, dan Agen Supervisor, dan Agen

Manajemen masalah pada ITIL v3 Service Operation Pemenuhan permintaan pada ITIL v3 Service Operation Manajemen akses pada ITIL v3 Service Operation Mengorganisir operasi layanan pada ITIL v3 Service Operation

Kepala departemen

2. Observasi Lapangan Observasi lapangan untuk melengkapi data yang diperoleh dari wawancara dengan pihak-pihak terkait. Observasi ini disusun berdasarkan tinjauan pustaka di 2.6. Perihal yang diobservasi terkait dengan perilaku agen IT Helpdesk, interaksi antar agen IT Helpdesk, kondisi ruangan tempat berkerja, dan suasana yang dirasakan dalam berkerja di ruangan tersebut. 3. Studi Dokumen Organisasi Universitas Indonesia


57

Mempelajari dokumen-dokumen organisasi yang terkait dengan layanan TI di lingkup PT Toyota Astra Financial Services. 4. Focus Group Discussion Melakukan diskusi kelompok yang terfokus. Anggota yang mengikuti diskusi kelompok ini adalah anggota yang terkait dengan manajemen operasi layanan TI di PT Toyota Astra Financial Services. 5. Artefak Aplikasi Melakukan pengamatan terhadap alat bantu/tools yang digunakan oleh tim IT Helpdesk dalam menjalankan operasional layanan TI. Selain itu juga membaca dokumentasi aplikasi dari tools yang tersebut 6. Benchmarking dengan perusahaan sejenis Melakukan benchmarking dengan manajemen operasi layanan pada IT Helpdesk di perusahaan lain. Hal yang dibandingkan adalah proses-proses pada operasi layanan IT Helpdesk.



BAB 4 ANALISIS DAN PEMBAHASAN

Penelitian ini menggunakan metodologi SSM yang alurnya dijelaskan pada BAB III. Setelah menyusun metodologi penelitian di BAB III maka langkah yang berikutnya adalah melanjutkan alur metodologi sebagai analisis dan pembahasan di BAB IV. Data Wawancara

4.1

Penulis melakukan wawancara dengan tim dan manajemen yang terlibat dalam IT Helpdesk. Dari hasil wawancara tersebut kemudian diketahui fungsi dan peran iCare, aplikasi yang digunakan oleh iCare, dan operasi layanan iCare saat ini. 4.1.1 Fungsi dan peran pada iCare Dalam menjalankan fungsinya dalam memberikan dukungan TI untuk kebutuhan operasional

bisnis,

iCare

masih

melekat

pada

departemen

IT

Application/Development (lampiran-5 transkrip R-101). Fungsi dari iCare adalah memberikan dukungan TI bagi operasional bisnis baik disisi aplikasi, peralatan TI, dan infrastruktur jaringan (lampiran-5 transkrip R-102). Pada iCare pada tingkat manajerial dibawah pimpinan IT Development Head (lampiran-5 transkrip R-101). Pada tingkat operasional iCare memiliki beberapa agen IT Helpdesk sebagai first level, seorang supervisor, dan IT Analyst sebagai second level support. 4.1.2

Layanan iCare

iCare menyediakan beberapa jenis layanan. Berdasarkan hasil wawancara dengan supervisor dan agen IT Helpdesk (lampiran-2 transkrip R-3, dan lampiran-4 transkrip R-65) layanan yang diberikan oleh iCare adalah sebagai berikut: 1. Problem adalah kendala permasalahan yang ditemukan oleh pengguna seputar sistem informasi dan fasilitas perangkat kerja TI yang digunakan. Misalnya: sistem error ketika menjalankan task / proses, abnormal flow

58



59

process, isu network performance, printer rusak, layout atau data tidak sesuai, dan lain-lain (lampiran-4 transkrip R-65, dan lampiran-2 transkrip R-7). 2. Request adalah permintaan pelayanan dari pengguna yang masuk ke iCare untuk menunjang kegiatan pekerjaan mereka ketika berinteraksi dengan sistem informasi dan perangkat kerja TI. Misalnya: unlock password komputer atau akun surel, permintaan cetak ulang dokumen polis, permintaan cetak ulang dokumen kontrak, Change Data Request (CDR), User Request Form (URF) untuk permintaan pembuatan akun login baru, perubahan akun pengguna, hardware devices), dan lain-lain (lampiran-2 transkrip R-4, lampiran-2 transkrip R-5, dan lampiran-4 transkrip R-65). 3. Information adalah pelayanan interaksi antara user dengan iCare terkait dengan kebutuhan pengetahuan seputar sistem informasi yang digunakan atau kebutuhan data yang tersimpan di dalamnya. Misalnya: informasi flow proses pada aplikasi, informasi last update dan modifier data, informasi nomor polis asuransi, informasi status aplikasi, dan lain-lain (lampiran-2 transkrip R-6, dan lampiran-4 tranksrip R-65). Pada transkrip wawancara lampiran-2 transkip R-9, lampiran-4 transkrip R67, dan lampiran-2 transkrip R-21, permintaan masuk memalui beberapa jalur antara lain: 1. Surat Elektronik (surel)/Email 2. Telepon IP (disertai IVR) 3. Telepon dengan saluran analog (disertai IVR) 4. Telepon seluler 5. Aplikasi E-Dora Operasi layanan iCare adalah pukul 07:00-18.00 WIB dari senin hingga jumat dan 08:00-14:00 untuk hari sabtu. iCare miliki belum tersusun dalam suatu layanan panduan formal (lampiran-4 transkrip R-67).



60

4.1.3

Operasi Layanan iCare

Melalui wawancara dengan supervisor, IT Analyst, dan agen iCare maka didapatkan proses operasi layanan iCare terkait dengan penanganan permintaan yang masuk. Berikut adalah proses penangan iCare terhadap permintaan yang masuk: 1. IT Helpdesk menerima pelayanan dari pengguna melalui surel/telepon/mobile phone (lampiran-4 transkrip R-69). Beberapa pengguna kadang ada yang langsung mengirim surel ke 2nd level (lampiran-3 transkrip R-59). 2. IT Helpdesk melakukan identifikasi pelayanan yang diterima. Identifikasi ini terkait dengan wewenang dan keahlian (lampiran-4 transkrip R-69). 3. IT Helpdesk langsung memproses dan menyelesaikan pelayanan yang masuk apabila dalam wewenang dan keahlian yang dimiliki (lampiran-4 transkrip R69) baik insiden (lampiran-4 transkrip R-73) ataupun bukan. a. Jika pelayanan adalah suatu insiden dan tidak selesai di 1st level maka naik ke supervisor. Supervisor melakukan analisis. Apabila langsung bisa diselesaikan supervisor maka diselesaikan di supervisor, jika tidak maka dikoordinasikan dengan 2nd level. Diskusi antar 2nd level di head office juga dilakukan bila perlu (lampiran-3 transkrip R-40) karena ada kemungkinan insiden yang sedang dihadapi pernah dihadapi oleh 2nd level yang lain. 2nd level yang teringat dengan insiden dapat mencari solusinya di aplikasi issue log tetapi informasi yang ada terbatas dan bergantung kepada ingatan dan kebiasaan menulis dari 2nd level (lampiran-3 transkrip R-48). Jika tidak dapat diselesaikan secara internal maka diteruskan ke vendor aplikasi untuk diselesaikan (lampiran-4 transkrip R-73). Monitoring pelayanan yang dieskalasi di-monitor oleh iCare menggunakan aplikasi pencatatat issue log (lampiran-4 transkrip R-73). Solusi yang diberikan dapat berupa solusi jangka pendek untuk kasus dengan tingkat urgensitas di lapangan. Jika termasuk genting maka dicarikan solusi jangka pendeknya termasuk menyarankan mekanisme Universitas Indonesia


61

manual dengan menginformasikan kepada atasan pengguna yang melapor. Untuk solusi jangka panjang dikoordinasikan dengan IT Development Head (lampiran-4 transkrip R-88). Keputusan apakah masalah genting atau tidak ada pada Supervisor (lampiran-4 transkrip R89) dan kemudian dicatat kedalam issue log. Untuk jangka panjang dieskalasi ke vendor. Jika tidak ada solusi jangka pendek maka agen menginformasikannya ke pengguna bahwa penyelesaian membutuhkan waktu lebih lama (lampiran-2 transkrip R-26). b. Jika pelayanan adalah suatu request maka dilihat terlebih dahulu apakah dalam wewenang tim iCare atau tidak jika tidak dalam wewenang, maka iCare menyampaikan prosedur permintaan/request melalui aplikasi EDora (lampiran-4 transkrip IR-78). Jika sudah ada permintaannya di EDora maka jika memang bisa diselesaikan maka diselesaikan oleh iCare, jika tidak maka dieskalasi ke 2nd Level (lampiran-2 transkrip R-18). Request memiliki prioritasnya lebih rendah dibandingkan yang merupakan suatu insiden (lampiran-3 transkrip R-52). c. Jika pelayanan yang diminta terkait dengan manajemen akses maka pengguna diarahkan untuk mengajukan permintaan dalam bentuk URF melalui aplikasi E-Dora (lampiran-4 transkrip R-91 dan lampiran-2 transkrip R-20). 4. Untuk setiap pelayanan yang sudah selesai dikerjakan, IT Helpdesk menginformasikan kepada pelapor/pengguna melalui jalur surel (lampiran-4 transkrip R-69). Baik tim iCare maupun 2nd level dapat langsung membalas surel kepada pengguna (lampiran-4 transkrip R-75) 5. IT Helpdesk melakukan pencatatan atas setiap pelayanan yang sudah diselesaikan ke dalam aplikasi pencatatan (lampiran-4 transkrip R-69) menggunakan aplikasi sederhana berbasis web bernama issue log (lampiran-4 transkrip R-70, dan lampiran-4 transkrip R-71).



62

4.2

Artefak Aplikasi

Penulis melakukan wawancara dari aplikasi yang digunakan oleh iCare. Diketahui dari hasil wawancara tersebut bahwa iCare menggunakan aplikasi Issue Log dan E-Dora. 4.2.1

Issue Log

Tim IT Helpdesk menggunakan aplikasi “issue log” yang dikembangkan secara internal untuk melakukan pencatatan dari masalah yang masuk. Sifatnya hanya berupa log dengan beberapa fitur. Issue log dilengkapi dengan intergrasi ke Active Directory untuk memastikan akun yang masuk ke aplikasi pencatatan adalah benar bagian dari tim iCare. Catatan log mencakup informasi sebagai berikut : 1. Jenis permintaan yang terdiri dari problem, request, dan Informasi. 2. Cabang yang meminta bantuan iCare 3. Kategori permintaan yang tediri dari User Admin, Sales, Service, Collection, Insurance, Infrastruktur, General Affairs, dan lain-lain. 4. Status permintaan masuk dari saluran informasi yang mana. Saluran informasi pada aplikasi ini dikategorikan menjadi Email, Telepon, dan lainlain. 5. Deskripsi permintaan bantuan. 6. Agen IT Helpdesk yang menjadi PIC (Person in Charge) dari permintaan ini. 7. Status permintaan apakah masih Open atau Closed. Berikut adalah tampilah masukan pada aplikasi “Issue Log”.



63

Gambar 4.1 Tampilan input new issue pada aplikasi issue log Untuk agen yang memiliki issue yang masih open maka terlampir di bagian bawah halaman.



64

Gambar 4.2 Informasi open new pada aplikasi issue log Issue yang masih open bisa dilakukan follow up berupa pergantian PIC, perubahan issue type, perubahan cabang, perubahan deskripsi, dan perubahan status open atau closed. Aplikasi dapat mengeksport semua datanya untuk dimilki kepada supervisor. 4.2.2

E-Dora

Aplikasi E-Dora merupakan singkatan dari Electronic Digital Online Request Application yang dibangun secara internal. Aplikasi ini diintergrasikan ke Active Directory untuk memastikan login adalah benar karyawan Toyota Astra Finance.



65

Gambar 4.3 Halaman muka aplikasi E-Dora Pada aplikasi ini pengguna dapat mengajukan beberapa hal ke bagian IT, General Affairs, dan Finance. Untuk hal yang ajukan ke bagian IT adalah: 1. CDR (Change Data Request) Permintaan perubahan data pada aplikasi. Pada menu pengisian hanya disediakan pilihan aplikasi Esster (Employee Self Service Terminal), Confins (Core System operasional Toyota Astra Finance), dan Axapta (Core System backend Toyota Astra Finance). Pengguna diminta mengisi key data (misal nomor kontrak) dari data yang akan diubah, data semula, data setelah berubah, alasan mengapa mengajukan CDR, dan orang yang diminta persetujuan atas CDR ini. Orang yang diminta persetujuan atas CDR adalah atasan lansung dan atasan tidak langsung atau 2 tingkat diatasnya. Untuk perubahan data tertentu diharuskan untuk memilih atasan tidak langsung. Secara panduan pelaksanaan tetapi hal ini masih manual.



66

Setelah diberikan oleh atasan pengguna maka CDR masuk ke TI untuk dilakukan beberapa aktivitas yang dapat dilakukan oleh semua staf TI yang login ke E-dora yaitu: a. Penugasan ke staf TI. b. Penugasan ulang ke staf TI lain. c. Penutupan dari permintaan CDR tersebut bahwa perubahan data sudah dilakukan. d. Penolakan perubahan data dalam CDR dilengkapi dengan alasannya. Pada saat staf TI melakukan penutupan atau penolakan permintaan CDR, maka E-dora secara otomatis mengirimkan surel kepada pengguna yang melakukan request CDR tersebut.

Gambar 4.4 Halaman input CDR pad aplikasi E-Dora 2. URF (User Request Form) Permintaan terkait dengan hak akses dan username. penambahan, penghapusan, dan pengubahan akses dari user untuk aplikasi-aplikasi yang ada di Toyota Astra Finance baik core system, email, user PC (Active Directory), dan aplikasi-aplikasi penunjang lainnya. Universitas Indonesia


67

Informasi yang dimasukan dalam mengajukan URF adalah pengajuan yaitu User Administration, IT Devices, dan Software Tools. Untuk tiap jenis URF yang berbeda maka informasi yang dimasukan pun menyesuaikan. Persetujuan approval dimulai dengan atasan pengguna, bisa atasan langsung maupun atasan tidak langsung, kemudian setelah disetujui masuk ke IT Development Head untuk URF User Administration atau IT Infrastructure Head untuk URF IT Devices dan Software Tools. Setelah dari pimpinan departemen TI maka URF ditugaskan kepada seorang staf TI untuk dikerjakan dan kemudian melakukan penutupan URF setelah URF selesai dikerjakan. 3. URFA (User Request Form Application) Permintaan

terkait

dengan

pemenuhan

permintaan

pengguna

untuk

pembuatan aplikasi baru, pengubahan fungsi aplikasi, pembuatan atau pengubahan laporan/reporting, dan permintaan data untuk keperluan pengolahan data. Setelah pengguna membuat URFA maka persetujuan dari pihak atasan pengguna adalah sebanyak dua lapis, yaitu atasan langsung dan atasan tidak langsung (atasan dari atasan langsung). Kemudian URFA masuk ke IT Development Head untuk ditugaskan kepada seorang staf TI. Setelah staf TI mengerjakan URFA tersebut maka melalui aplikasi E-dora selanjutnya staf TI menaikan status URFA menjadi user acceptance test (UAT). Saat hal ini dilakukan E-Dora mengirim surel kepada pengguna yang membuat URFA. Komunikasi dan proses UAT antara pengguna dengan staff TI dilakukan manual tanpa melalui E-Dora. Setelah UAT dinyatakan selesai oleh pengguna, maka pengguna menaikan status URFA menjadi closing dimana E-Dora akan mengirim notifikasi ke staf TI yang menangani URFA tersebut. Saat inilah kemudian staf TI melakukan deployment ke production enviroment dengan waktu yang telah disepakati sebelumnya. Setelah itu URFA dilakukan penutupan oleh staf TI di E-dora.



68

4.3

Observasi di IT Helpdesk / iCare

Peneliti melakukan observasi di ruangan iCare pada jam kerja operasional untuk mengetahui beberapa hal berikut: 1. Karakteristik dari individu, termasuk cara berpakaian, bahasa tubuh, dan perilaku non-verbal. 2. Interaksi antara individu. 3. Aksi yang dilakukan, baik manusia maupun mesin. 4. Fisik dari sekeliling, termasuk visual dan audio. Dengan melakukan pengamatan dari jam 08.00 WIB hingga jam 12.00 WIB diketahui bahwa: 1. Karakteristik dari individu a. Agen memiliki perhatian kepada request yang masuk dan ramah dalam menjawab telepon dan email. b. Pakaian yang dipergunakan casual dan santai. c. Agen yang bertugas sebanyak 3 orang dengan 1 orang supervisor. 1 dari 2 agen yang bertugas mengerti hal-hal terkait masalah jaringan sedangkan 2 agen yang lain lebih mengerti masalah aplikasi operasional. Agen adalah karyawan outsource sedangkan supervisor adalah karyawan internal. 2. Interaksi antara individu a. Komunikasi antar agen terjalin dengan akrab serta humoris. b. Koordinasi antara agen dengan supervisor lancar dan akrab. Agen sering meminta petunjuk dari supervisor untuk beberapa hal sehingga ada ketergantungan agen dengan supervisor terkait dengan persetujuan untuk penanganan (otoritas) dan informasi pemecahan masalah. c. Agen

diizinkan

berkerja

sambil

mendengarkan

musik

melalui

headphone. Tampaknya hal ini tidak menjadi masalah karena telepon Universitas Indonesia


69

yang masuk dapat direspon oleh Agen dengan melihat lampu LED yang berkedip pada pesawat telepon. 3. Aksi yang dilakukan, baik manusia maupun mesin. a. Aksi yang dilakukan oleh agen antara lain pengoperasian beberapa aplikasi yang memang diperuntukan untuk iCare, membantu menangani permintaan pengguna melalui telepon via VOIP, dan melakukan eskalasi permintaan melalui telepon VOIP ke supervisor atau analis TI di kantor pusat. b. Agen melakukan komunikasi melalui surel. Eskalasi dilakukan dengan meneruskan surel kepada analis TI baik dengan memberikan carbon copy/CC kepada pengguna ataupun tidak. c. Agen membalas telepon menggunakan telepon seluler khusus milik iCare sebanyak 1 unit untuk menghubungi pengguna yang sedang tidak berada di kantor. Hal ini dilakukan karena untuk pengguna yang sedang berada di dealer mobil atau di luar kantor untuk mendapatkan respon yang cepat. Selain itu agen juga dapat merespon dan membalas permintaan memalui SMS menggunakan telepon seluler tersebut. Karena hanya 1 unit telepon seluler maka hanya dapat merespon 1 permintaan pada 1 waktu untuk permintaan-permintaan yang ditanggapi melalui telepon seluler. d. Agen merespon permintaan sesuai dengan cara masuk permintaan. Jika masuk melalui surel maka direspon menggunakan surel, jika masuk melalui telepon maka dibalas melalui telepon, dan seterusnya. e. Agen mengerjakan permintaan menggunakan thin client, (bukan notebook maupun PC), dengan layar, mouse, dan keyboard yang memadai. f. Untuk beberapa hal agen mampu memberikan penjelasan langsung ataupun mengerjakan langsung permintaan tanpa menutup telepon. Sehingga permintaan tertentu dapat selesai dalam satu kali telepon. Universitas Indonesia


70

g. Saat menelepon iCare, pengguna direspon oleh mesin IVR dengan beberapa pilihan bantuan yaitu permintaan terkait aplikasi, permintaan terkait jaringan, dan permintaan terkait general affair/GA. Untuk pilihan permintaan jaringan maka disambukan ke 1 agen yang mengerti jaringan, sedangkan untuk pilihan permintaan lainnya disebar kesemua agen IT helpdesk. 4. Fisik dari lingkungan kerja a. Lokasi iCare bergabung dengan gedung cabang kelapa gading berupa ruko 4 lantai. Lantai 1 dan 2 untuk operasional cabang, lantai 3 untuk ruang meeting, pantry, mushola, ruang server. Lantai 4 ada gudang dan ada ruangan iCare. Ruangan iCare memiliki luas 4x8 meter dilengkapi dengan 2 pendingin ruangan. Tiap lantai terdapat kamar kecil/toilet. b. Ruangan iCare memiliki monitor besar, dispenser, loker pribadi, 1 unit printer, dan 2 white board besar. c. Meja kerja iCare berupa meja kubikal ukuran 120x80 cm dari kayu. Sekat meja cukup tinggi. Meja memiliki laci keyboard dan laci barang. Pada meja juga terdapat kabel network UTP dan perpanjangan kabel listrik. d. Peralatan kerja dimeja terdapat IP-Phone, monitor LCD 15 inci, keyboard, mouse, dan perangkat thin client yang terhubung ke server thin client di lantai 3. e. Supervisor memiliki meja sendiri dan memiliki peralatan yang sama dengan agen tetapi untuk berkerja supervisor menggunakan notebook. f. Suasana diruangan hening. Sesekali ada suara dering telepon dan percakapan agen baik dengan agen lain atau dengan pengguna di telepon. Suasana hening ini cukup mendukung pekerjaan iCare yang memerlukan aktivitas berbicara melalui telepon



71

4.4

Mengekspresikan Situasi Bermasalah

Berdasarkan tahapan SSM maka setelah didapatkan data-data dari pembahasan 4.1 hingga 4.3 maka operasi layanan IT Helpdesk di Toyota Astra Finance digambarkan dalam bentuk rich picture sebagai berikut:

Gambar 4.5 Rich picture kondisi saat ini 4.5

Membuat root definition

Setelah dipahami situasi saat ini dan mendapatkan data-data pendukung lain, tahapan selanjutnya adalah pemilihan dan penamaan root definition dari sistem yang relevan. Penyusunan root definition menggunakan alat bantu analisis CATWOE

(Customers,

Actors,

Transformation,

Worldview,

Owners,

Enviromental Constraints). Root definition ini selanjutnya digunakan untuk membuat model konseptual dari manajemen operasi layanan IT Helpdesk.



72

Tabel 4.1 Tabel analisa CATWOE Aspek Customers

Actors

Analisis CATWOE

Data Pendukung

Seluruh pegawai yang menggunakan layanan Lampiran-5 transkrip TI di Toyota Astra Finance

R-102

Tim IT Helpdesk

Transkrip wawancara dengan Supervisor iCare, Agen IT Helpdesk, dan IT Analyst

Transformation Memberikan layanan dukungan TI bagi Lampiran-5 transkrip operasional bisnis baik aplikasi, peralatan TI, R-102 dan infrastruktur jaringan. World view

Owners

Menjaga performa bisnis dari gangguan yang Lampiran-5 transkrip terkait dengan TI

R-102

IT Development Department Head

Lampiran-5 transkrip R-101

Environmental

Kewenangan layanan yang dimiliki tim IT Transkrip wawancara

Constraints

Helpdesk.

dengan

Supervisor

iCare

Berdasarkan dari tabel analisis CATWOE maka didapatkan root definition: Suatu manajemen operasi layanan IT Helpdesk yang dimiliki oleh IT Development OWNERS Department dan dikelola oleh tim IT Helpdesk dengan memberikan layanan ACTORS dukungan TI bagi operasional bisnis baik aplikasi, peralatan TI, dan TRANSFORMATION infrakstruktur jaringan agar seluruh pegawai Toyota Astra Finance yang CUSTOMERS menggunakan layanan TI dapat menjaga performa bisnis dari gangguan yang WORLDWIDE Universitas Indonesia


73

terkait dengan TI sesuai dengan kewenangan layanan yang dimiliki oleh tim ENVIRONMENTAL CONSTRAINTS IT Helpdesk. 4.6

Membuat model konseptual

Tahapan berikutnya dalam SSM adalah penyusunan model konseptual. Model konseptual dibuat dengan memikirkan dan menuliskan aktivitas (holon) minimum yang dirasa dibutuhkan untuk menjalankan proses transformasi. Holon berupa kalimat kerja yang mendefinisikan aktivitas nyata yang dapat dilakukan manusia. Aktivitas ini disusun secara logis dalam hal interaksi antar aktivitas dan menunjukan ketergantungan satu sama lain. Dalam penyusunan model konseptual manajemen operasional layanan IT Helpdesk di Toyota Astra Finance, penulis berdasarakan pada root definition yang sudah dibuat pada pembahasan 4.5, benchmarking dengan perusahaan pembiayaan lain, dan best practice dari operasi layanan ITIL v3. Pada pembahasan 4.5, root definition dari penelitian adalah “suatu manajemen operasi layanan IT Helpdesk yang dimiliki oleh IT Development Department dan dikelola oleh tim IT Helpdesk dengan memberikan layanan dukungan TI bagi operasional bisnis baik aplikasi, peralatan TI, dan infrakstruktur jaringan agar seluruh pegawai Toyota Astra Finance yang menggunakan layanan TI dapat menjaga performa bisnis dari gangguan yang terkait dengan TI sesuai dengan kewenangan layanan yang dimiliki oleh tim IT Helpdesk” 4.6.1 Benchmarking dengan PT Bussan Auto Finance PT Bussan Auto Finance (BAF) adalah perusahaan pembiayaan yang saat ini berkonsentrasi pada pembiayaan motor Yamaha. BAF didirikan pada tahun 1997. Komposisi pemegang sahamnya adalah 70% Mitsui & Co.,Ltd, 20% Yamaha Motor Co.,Ltd, dan 10% PT Ciptadana Capital. Saat ini BAF memiliki 173 kantor cabang di seluruh pelosok Nusantara, dengan jumlah karyawan lebih dari 10,000 orang. Total jumlah konsumen yang pernah dan sedang dibiayai oleh BAF telah mencapai lebih dari 4 juta orang. Selama



74

tahun 2009, BAF membiayai lebih dari 714 ribu unit kendaraan bermotor baru. Total aset lebih dari 10 triliun rupiah. Berdasarkan hasil wawancara dengan IT Analyst di BAF (lampiran-6 transkrip R109), diketahui bahwa IT Helpdesk di BAF berperan sebagai pintu menerima permintaan keluhan pengguna, menyaring keluhan dan meneruskan informasi, melakukan pencatatat keluhan, dan melakukan prioritas keluhan yang perlu di respon cepat. Fungsi yang dimiliki seperti IT Helpdesk di Toyota Astra Finance, kecuali belum ada prioritas keluhan di IT Helpdesk Toyota Astra Finance. Secara kapasitas IT Helpdesk di BAF memiliki lebih banyak personil dan lebih banyak cabang yang dilayani (lampiran-6 transkrip R-110). Jenis permintaan yang dilayani IT Helpdesk BAF sama-sama meliputi aplikasi, peralatan TI, maupun infrastruktur jaringan tetapi pada BAF belum ada kategorisasi permintaan (lampiran-6 transkrip R-111). Jalur masuk permintaan IT Helpdesk BAF dengan Toyota Astra Finance sama-sama memiliki jalur surel, telepon, dan formulir aplikasi, bedanya IT Helpdesk Toyota Astra Finance memiliki jalur SMS sedangkan BAF memiliki jalur tambahan formulir kertas (lampiran-6 transkrip R112). Perbedaan cara penanganan permintaan yang masuk IT Helpdesk BAF dengan Toyota Astra Finance adalah pada BAF permintaan yang masuk dicatat pada aplikasi manajemen tiket open source mantis, sedangkan pada Toyota Astra Finance pencatatan dilakukan tidak selalu sesaat setelah permintaan masuk, tetapi bisa saja dimasukan setelah permintaan dikerjakan di aplikasi log buatan internal yang bernama issue log (lampiran-6 transkrip R-113). Untuk proses selanjutnya dimana ada penanganan agen IT Helpdesk dan eskalasi sama seperti yang dilakukan Toyota Astra Finance (lampiran-6 transkrip R-114). Proses pemecahan masalah pada IT Helpdesk BAF sama dengan Toyota Astra Finance dimana pada BAF digunakan istilah tim ahli sedangkan pada Toyota Astra Finance menggunakan istilah 2nd level support. Tim ahli/2nd level support ini sama-sama juga melakukan pencatatan pada system (lampiran-6 transkrip R-115). Pada IT Helpdesk Toyota Astra Finance dan BAF khusus untuk perubahan akses



75

diharuskan melalui mengisi permohonan perubahan pada aplikasi terpisah (lampiran-6 transkrip R-117). Tabel 4.2 Hasil benchmarking dengan BAF Hal yang dibandingkan Fungsi IT Helpdesk Kapasitas SDM kapasitas operasi layanan Jenis layanan Jalur komunikasi Penanganan permintaan

Pemecahan masalah Perubahan hak akses

4.6.2

Perbedaan Tidak ada BAF lebih banyak personil BAF melayani lebih banyak cabang BAF belum dilakukan kategorisasi Sama kecuali Toyota Astra Finance ada SMS dan BAF ada formulir kertas. BAF langsung melakukan pencatatan di aplikasi ticketing. TAFS melakukan pencatatan diakhir sebagai log. Tidak ada Tidak ada

Operasi Layanan ITIL v3

Terkait dengan event management, jalur informasi yang masuk hanya melalui pengguna. Pada manajemen event operasi layanan ITIL v3, event masuk juga melalui notifikasi yang dihasilkan secara otomatis, misalnya notifikasi jaringan putus, atau server mati, kegagalan perangkat keras dan sebagainya. Event ini kemudian didilakukan filter apakah signifikan atau tidak. Jika hanya berupa informasi maka dicatat. Event yang dianggap peringatan diproses sistem baik dengan memberikan respon secara otomatis untuk perbaikan atau dengan memberikan alert untuk dilakukan intervensi manusia. Event yang dianggap pengecualian maka dipilah apakah masuk insiden, masalah, atau perubahan. Aksi yang sudah dilakukan kemudian dilakukan peninjauan apakah sudah efektif atau belum. Jika belum maka diproses ulang. Jika sudah efektif baru event dinyatakan ditutup. Manajemen insiden yang dilakukan pada IT Helpdesk Toyota Astra Finance memiliki saluran informasi masuk formulir web, telepon, dan surel sehingga hanya satu saluran saja yang tidak termasuk dari manajemen insiden ITIL v3 yaitu saluran insiden dari manajemen event. Insiden yang masuk dilakukan pencatatan setelah diidentifikasi seperti yang dilakukan oleh IT Helpdesk BAF, sedangkan Universitas Indonesia


76

pada IT Helpdesk Toyota Astra Finance pencatatan dilakukan diakhir. Pada IT Helpdesk saat ini sudah agen sudah melakukan pemilahan apakah termasuk pemenuhan permintaan atau bukan. Jika berupa pemenuhan permintaan maka agen IT Helpdesk menginformasikan kepada pengguna untuk menggunakan formulir web, dan jika sudah ada maka baru dikerjakan atau dieskalasi jika di luar kemampuan agen. Saat ini IT Helpdesk belum memberikan prioritas apakah insiden termasuk insiden yang sifatnya major atau tidak seperti pada manajemen insiden ITIL v3, sehingga insiden langsung dilakukan diagnosa. Proses eskalasi pada IT Helpdesk sudah ada ada yaitu kepada supervisor atau 2nd level terkait wewenang dan keahlian. Eskalasi hierarkis ke manajemen untuk saat ini belum ada. Proses eskalasi hierarkis dilakukan manual melalui supervisor. Investigasi dan diagnosis lanjutan terkait insiden sudah dilakukan pada proses IT Helpdesk saat ini. kemudian dilanjutkan dan diberikan resolusi dan pemulihan insiden. Insiden kemudian dilakukan ditutup jika sudah diberikan solusi. Saat ini proses tersebut sudah sesuai dengan manajemen insiden ITIL v3. Terkait dengan manajemen masalah saat ini apa IT Helpdesk hanya masuk dari insiden saja, sedangkan pada manajemen masalah ITIL v3 meliputi manajemen event, manajemen masalah proaktif, dan vendor. Pencatatan masalah pada saat ini masih berdasarkan insiden sehingga tidak nampak apakah ada masalah yang menghasilkan beberapa insiden. Belum ada pengkategorian dan pemberian prioritas masalah. Belum ada Change Management System (CMS) yang membantu dalam melakukan investigasi dan diagnosa. Pemberian solusi jangka pendek hanya mengandalkan ingatan dari masing-masing anggota tim karena belum ada known-error database. Jika perubahan diperlukan untuk mengatasi masalah maka tidak ada pencatatan di CMS karena sebagaimana yang sudah disebutkan sebelumnya belum ada CMS. Karena belum ada pemberian kategori dan prioritas masalah maka tidak dilakukan peninjauan dari masalah yang sifatnya major. Dari analisis didapatkan beberapa aktivitas yang direkomendasikan oleh ITIL v3 tetapi belum ada di proses operasi layanan IT Helpdesk Toyota Astra Finance saat ini. Berikut adalah rekomendasi aktivitas dari operasi layanan ITIL v3. Universitas Indonesia


77

Tabel 4.3 Perbandingan proses saat ini dengan operasi layanan ITIL v3    



Manajemen event Adanya notifikasi event secara otomatis. Adanya pemilahan signifikansi event. Adanya response otomatis dari sistem. Adanya alert yang dikirim kepada manusia/staff TI. Melakukan peninjauan dari aksi yang sudah dilakukan.

4.6.3

Manajemen Insiden  Adanya saluran masuk insiden dari event manajemen.  Melalukan pencatatan insiden sebelum melakukan penanganan lebih lanjut.  Adanya pemilihan insiden yang bersifat major.  Adanya eskalasi hierarkis kepada manajemen.

Manajemen Masalah  Adanya saluran manajemen masalah dari manajemen event, manajemen masalah proaktif, dan vendor.  Pemisahaan pencatatan antara insiden dan masalah.  Adanya kategorisasi masalah.  Adanya prioritas penanganan masalah.  Membuat Change Management System (CMS).  Membuat Known Error Database.  Melakukan peninjauan masalah yang bersifat major.

Model konseptual

Dengan mempertimbangkan root definition, analisis benchmarking dengan BAF, dan analisis operasi layanan ITIL v3 yang diterbitkan oleh OGC (2007) maka disusunlah model konseptual sebagai berikut:



78

Gambar 4.6 Model konseptual Pada model konseptual terdapat 13 aktivitas. Penjelasan dari aktivitas adalah sebagai berikut: 1. Mengelola generator notifikasi event Event yang terjadi tidak selalu datang dari laporan pengguna. TI dapat membuat suatu generator notifikasi dari event-event yang terjadi secara otomatis, misalnya koneksi jaringan putus, server mati, penggunaan processor server yang tinggi, adanya aktivitas pengguna yang mencurigakan seperti melakukan reset password berkali-kali, dan sebagainya. Dengan membuat generator notifikasi event maka IT Helpdesk dapat merespon kejadian yang belum atau tidak dilakukan oleh pengguna. 2. Mengelola pemilahan event



79

Notifikasi yang masuk secara otomatis dipilah-pilah berdasarkan tingkat kepentingan event. Apakah event merupakan informasi, peringatan, atau pengecualian. 3. Melakukan penanganan event Apabila event adalah informasi maka event dicatat. Apabila suatu peringatan maka dilakukan proses korelasi event yang hasilnya menentukan apakah event direspon secara otomatis atau memberikan peringatan untuk dilakukan intervensi oleh manusia/staf TI. Jika event

adalah pengecualian maka

diproses melalui penanganan insiden, penanganan masalah, atau penanganan perubahan. 4. Menerima insiden yang masuk Insiden yang masuk selain datang dari laporan pengguna juga dapat datang dari manajemen event sebagai mana dijelaskan pada nomor 3 diatas. Insiden kemudian di identifikasi dan dicatat kedalam suatu log. Insiden kemudian dicek apakah masuk kategori pemenuhan permintaan (request fulfilment), jika benar dan belum menyertakan pengajuan dari aplikasi E-Dora maka agen menginformasikan kepada pengguna untuk membuat terlebih dahulu. Jika sudah dibuat maka proses pemenuhan permintaan dilanjutkan apabila sesuai wewenang dan keahlian atau dieskalasi jika tidak. Apabila insiden tidak termasuk dalam pemenuhan permintaan (request fulfilment) maka dilakukan pengecekan apakah masuk insiden major atau tidak. Jika insiden adalah major maka diproses dengan prosedur berbeda dan jika bukan major maka dilakukan penangan insiden. 5. Melakukan penangan insiden Insiden dicek apakah memerlukan eskalasi fungsional, jika memerlukan eskalasi fungsional maka dilakukan eskalasi ke supervisor atau 2nd level. Jika memerlukan eskalasi hierarkis maka dilakukan eskalasi kepada manajemen. Agen IT Helpdesk/1st Level melalukan investigasi dan diagnosa insiden. Setelah diketahui penyebabnya kemudian melakukan resolusi insiden dan Universitas Indonesia


80

pemulihan insiden. Jika insiden dieskalasi maka supervisor atau 2nd Level melakukan deteksi masalah. 6. Mengelola manajemen masalah proaktif IT helpdesk mengelola suatu manajemen masalah proaktif yang merupakan bagian dari peningkatan layanan yang berkelanjutan. Masalah yang muncul dari bagian ini adalah inisiatif-inisiatif dalam meningkatkan layanan IT Helpdesk. 7. Mendeteksi masalah Masalah terdeteksi dari laporan pengguna, manajemen event, manajemen insiden,

manajemen

masalah

proaktif,

maupun

masalah

dari

supplier/kontraktor. 8. Melakukan penanganan masalah Masalah yang terdeteksi dicatat dipencatatan yang berbeda dengan pencatatan insiden. Kemudian masalah dikategorisasi dan diberi prioritas penanganan. Masalah selanjutnya dilakukan investigasi dan diagnosa. Jika masalah memerlukan perubahan pada system maka dicatat di Change Management System (CMS). Proses diagnosa juga dapat memanfaatkan CMS untuk mengetahui dampak perubahan atau perubahan apa yang kemungkinan berpengaruh

kepada

masalah.

Jika

ditemukan

solusi

jangka

pendek/workaround maka dicatat pada known-error database. Saat mencari solusi jangka pendek dapat juga mencari dari known-error database. Jika diperlukan solusi jangka panjang yang memerlukan perubahan maka perubahan di sistem maka perubahan dapat dilakukan dan mengupdate CMS melalui mekanisme mnajamen perubahan. 9. Mengelola known-error database Sebagaimana yang disebutkan pada aktivitas melakan penanganan masalah, diperlukan pengelolaan dari known-error database. Semua error yang sudah diketahui solusi jangka pendeknya dicatat pada basisdata ini sehingga



81

memudahkan diagnosa dan pencarian solusi masalah yang sama dikemudian hari. 10. Mengelola CMS Change Management System (CMS) berisi semua komponen dari infrastruktur TI termasuk dengan keterhubungan antar komponen. CMS menjadi sumber diagnosis masalah yang penting dan untuk evaluasi dampak dari masalah. Data yang aktivitas yang dimasukan dapat menjadi sumber data histori yang berharga untuk membantu mengidentifikasi tren masalah yang menjadi bagian penting dari manajemen masalah proaktif. 11. Meninjau efektivitas penanganan Dengan banyakanya event yang masuk setiap hari maka tidak diharuskan secara formal melakukan peninjauan dari semua event satu per satu. Peninjauan penting untuk dilakukan terhadap event yang signifikan/event pengecualian yang ditangani dengan benar. Dapat juga dilakukan dengan mengambil data secara otomatis dari catatan sistem. 12. Monitor/Mengawasi Pengawasan dilakukan oleh owner dari IT Helpdesk yaitu IT Development Head dengan menggunakan kriteria pengukuran performa berupa: a. Efficacy : Apakah permintaan dukungan layanan TI terpenuhi? b. Efficiency : Berapa jumlah permintaan dukungan layanan TI yang terpenuhi? Apakah sumber daya IT Helpdesk digunakan dalam pemenuhan permintaan dukungan layanan TI dari pengguna? c. Effectiveness : Apakah pemenuhan permintaan dukungan layanan TI membuat operasional bisnis tidak terganggu oleh hal-hal terkait TI? 13. Mengambil tindakan Setelah pihak owner/manajemen melakukan pengawasan dari kriteria-kritera pengukuran performa maka selanjutnya manajemen mengambil tindakan untuk melakukan perbaikan/meningkatan operasi layanan IT Helpdesk. Universitas Indonesia


82

4.7

Membandingkan model konseptual dengan dunia nyata

Dengan melihat model konseptual yang sudah berhasil dibangun pada pembahasan 4.6 dan membandingkan kondisi didunia nyata saat ini pada pembahasan 4.4 maka disusun beberapa perbandingan model konseptual dengan dunia nyata sebagai berikut: Tabel 4.4 Perbandingan model konseptual dengan dunia nyata Aktivitas 1. Mengelola generator notifikasi event

2. Mengelola pemilahan event 3. Melakukan penanganan event 4. Menerima insiden yang masuk

5. Melakukan penanganan insiden 6. Mengelola manajemen masalah proaktif 7. Mendeteksi masalah

8. Melakukan penanganan masalah

Bagaimana aktivitas didunia nyata? Belum ada generator notifikasi event

Belum ada generator notifikasi event Belum ada generator notifikasi event Sumber masuk insiden hanya berasal dari laporan pengguna. Pencatatan tidak dilakukan setelah menerima insiden. Dan belum ada pengecekan apakah insiden yang bersifat major. Sudah ada eskalasi fungsional tetapi belum ada eskalasi hierarkis. Belum ada manajemen masalah proaktif. Pendeteksian masalah berasal dari laporan pengguna, manajemen insiden.

Pencatatan masalah sama dengan pencatatan insiden. Masalah tidak diberikan prioritas penanangan. Investigasi dan diagnosis belum menggunakan CMS. Mencari solusi jangka pendek belum menggunakan known-error database.

Komentar dan rekomendasi Membuat generator notifikasi event kemudian menjalankan aktivitas mengelola generator notifikasi event. Menjalankan aktivitas mengelola pemilahan event. Menjalankan aktivitas pengangan event. Menambahkan sumber masuk insiden dari manajemen event. Melakukan pencatatan insiden setelah menerima insiden dan melakukan pengecekan apakah insiden yang bersifat major. Menambahkan eskalasi hierarkis kepada manajemen. Membuat manajemen masalah proaktif dan mengelolanya. Menambahkan pendeteksian masalah yang berasal dari manajemen event, manajemen masalah proaktif, dan masalah yang berasal dari supplier/kontraktor. Membuat pencatatan yang berbeda antara masalah dan insiden. Membuat prioritas penanangan. Menggunakan CMS dalam investigasi dan diagnosa. Menggunakan known-error database untuk mencari solusi jangka pendek.



83 Tabel 4.4 Perbandingan model konseptual dengan dunia nyata (Sambungan) Aktivitas Bagaimana aktivitas didunia Komentar dan rekomendasi nyata? 9. Mengelola knownBelum ada known-error database Membuat known-error error database database dan mengelola known-error database. 10. Mengelola CMS Belum ada CMS Membuat CMS dan mengelola CMS Melakukan peninjauan 11. Meninjau Penanganan efektivitas berada efektivitas oleh tim IT efektivitas penanganan dilevel manajemen, belum ada peninjauan efektivitas penanganan Helpdesk. secara mandiri oleh tim. 12. Pengawasan sudah dilakukan oleh Sudah sesuai. Monitor/pengawasan manajemen. Sudah sesuai. 13. Mengambil Tindakan dari hasil pengawasan tindakan dilakukan oleh manajemen dengan memberikan dukungan kepada IT Helpdesk.

4.8

Menyusun perubahan

Setelah didapatkan gap dari model konseptual dan dunia nyata maka pada langkah berikutnya dari SSM adalah menyusun perubahan. Didalam termasuk mempertimbangkan budaya perusahaan, kebijakan perusahaan, dan hasil penelitian sebelumnya. 4.8.1

Budaya Perusahaan

Berdasarkan wawancara dengan IT Development Head pada lampiran-5 transkrip R-105, Toyota Astra Finance memiliki nilai utama yang diyakini sebagai budaya perusahaan yaitu excellent, profesionalisme, good relation, dan customer focus. Kemudian untuk menjalankan nilai dari perusahaan tersebut Toyota Astra Finance perilaku melayani yang tediri dari care, simple, dan fast. Nilai utama dan nilai perilaku ini juga dijelaskan pada modul pelatihan new employee dan modul pelatihan service culture Toyota Astra Finance milik human resource department. Care adalah peduli, yang artinya karyawan berperilaku siap membantu untuk memenangkan hati pelanggan. Termasuk didalamnya antusias, menanggapi pelanggan, berkata sopan, bersikap santun, bersedia membantu, peduli kesulitan orang lain, dan mengambil tanggung jawab pribadi.



84

Simple adalah sederhana, yang artinya peduli memberikan proses yang sederhana dan akurat. Termasuk didalamnya komunikasi yang mudah dipahami, membuat proses yang sederhana, tidak membuat duplikasi atau proses yang akurat, dan fleksibel dalam mencapai tujuan. Fast adalah cekatan, yang artinya mahir dalam memberikan layanan yang cepat melalui proses yang sinergi. Termasuk didalamnya memahami ruang lingkup tugas, melakukan tugas dengan cekatan, benar, dan minim kesalahan atau mahir, tidak melakukan kesalahan fatal yang merugikan orang lain. Jadi cekatan tetapi tidak mengorbankan kualitas. Berikut adalah analisis rekomendasi gap model konseptual dengan dunia nyata yang diverifikasi menggunakan budaya perusahaan. Tabel 4.5 Kesesuaian aktivitas model dengan budaya perusahaan Aktivitas

komentar dan rekomendasi

1. Mengelola generator notifikasi event

Membuat generator notifikasi event kemudian menjalankan aktivitas mengelola generator notifikasi event.

2. Mengelola pemilahan event

Menjalankan aktivitas mengelola pemilahan event.

3. Melakukan penanganan event

Menjalankan aktivitas pengangan event.

Terhadap budaya perusahaan Sejalan dengan nilai Care. Dengan membuat generator notifikasi event maka gangguan bisa langsung diproses tanpa menyulitkan pengguna untuk melapor terlebih dahulu. Sejalan dengan nilai Fast. Karena pemilahan event mempercepat proses penanganan event. Sejalan dengan nilai Care. Dengan membuat melakukan penanganan event maka gangguan bisa langsung diproses tanpa menyulitkan pengguna untuk melapor terlebih dahulu.



85 Tabel 4.5 Kesesuaian aktivitas model dengan budaya perusahaan (Sambungan) Aktivitas komentar dan rekomendasi Terhadap budaya perusahaan 4. Menerima insiden Menambahkan sumber masuk Sejalan dengan nilai Care. yang masuk insiden dari manajemen event. Dengan menambah sumber Melakukan pencatatan insiden masuk insiden melalui setelah menerima insiden dan manajemen event maka melalkukan pengecekan apakah gangguan bisa langsung insiden yang bersifat major. diproses tanpa menyulitkan pengguna untuk melapor terlebih dahulu. Penambahan pengecekan apakah insiden berisfat major atau tidak memempercepat proses dan sejalan dengan value Fast. 5. Melakukan Menambahkan eskalasi hierarkis Proses eskalasi hierarkis penanganan insiden kepada manajemen. jika berada di sisi IT helpdesk memudahkan pengguna, sejalan dengan value simple. 6. Mengelola Membuat manajemen masalah Dengan memiliki dan manajemen masalah proaktif dan mengelolanya. mengelola manajemen proaktif masalah proaktif maka masalah dapat diselesaikan sebelum muncul, sejalan dengan value Care. 7. Mendeteksi masalah

8. Melakukan penanganan masalah

Menambahkan pendeteksian masalah yang berasal dari manajemen event, manajemen masalah proaktif, dan masalah yang berasal dari supplier/kontraktor. Membuat pencatatan yang berbeda antara masalah dan insiden. Membuat prioritas penanangan. Menggunakan CMS dalam investigasi dan diagnosa. Menggunakan known-error database untuk mencari solusi jangka pendek.

Penambahan informasi pedeteksian masalah sejalan dengan value Care.

Pemisahan pencatatan masalah dan insiden dan penggunaan CMS dan known-error database mempercepat penanganan dikemudian hari, sejalan dengan value Fast. Prioritas penangan juga dapat mempercepat masalah yang kristis, sejalan dengan value Care.



86 Tabel 4.5 Kesesuaian aktivitas model dengan budaya perusahaan (Sambungan) Aktivitas komentar dan rekomendasi Terhadap budaya perusahaan 9. Mengelola knownMembuat known-error database Pengelolaan known-error error database dan mengelola known-error database mempercepat proses investigasi database. penangan masalah sehingga sejalan dengan value Fast. 10. Mengelola CMS Membuat CMS dan mengelola Pengelolaan CMS dapay CMS mempercepat proses diagnosa masalah dikemudian hari sehingga sejalan dengan value Fast. 11. Meninjau efektivitas penanganan

Melakukan peninjauan efektivitas oleh tim IT Helpdesk.

12. Monitor/pengawasan 13. Mengambil tindakan

Sudah sesuai.

-

Sudah sesuai.

-

4.8.2

Dalam value Fast terdapat juga arahan bahwa cepat tetapi tidak mengorbankan kualitas. Untuk itu adanya peninjauan efektivitas oleh tim IT Helpdesk sejalan dengan value Fast.

Kebijakan Perusahaan

Pada pembahasan 2.11 dijelaskan bahwa manajemen operasi layanan juga dipengaruhi oleh kebijakan perusahaan. Tetapi hasil wawancara dengan IT Development Head didapatkan bahwa tidak ada kebijakan perusahaan yang mengatur secara khusus operasional iCare sebagai IT Helpdesk Toyota Astra Finance (lampiran-5 transkrip R-106). 4.8.3

Challenges implementasi ITIL

Pada penelitian Jantti di tinjauan pustaka didapatkan 7 tantangan dalam peningkatan layanan baik dari sisi alat/tools dan proses. Berikut adalah pembahasan challenges implementasi ITIL dan saran dalam pengimplementasian model konseptual.



87

Tabel 4.6 Saran dari challenges implementasi ITIL Chalenges implementasi ITIL klarifikasi atas klasifikasi dari permintaan support yang jelas.

Kondisi pada model konseptual

Saran

Pada penanganan event kemudian dipilah-pilah insiden dan masalah termasuk pengkategorian insiden dan masalah.

-

Pelanggan tidak dapat melakukan klasifikasi permintaan support dengan benar.

Permintaan dukungan yang masuk dari telepon dan Email sulit untuk dilakukan sehingga klasifikasi permintaan support dilakukan oleh tim IT Helpdesk sesuai dengan model konseptual.

-

Sulit untuk melakukan identifikasi insiden yang berulang dari sistem service desk.

Pada model konseptual pencatatan insiden belum ada tautan antar insiden.

Membuat tautan antar insiden sehingga dapat diketahui bahwa insiden berulang.

pengguna tidak ada mengetahui perbedaan antara insiden dan masalah Ide peningkatan tidak dicatat secara sistematis ke dalam sistem service desk

Pada model konseptual pencatatan insiden dan masalah dilakukan oleh IT Helpdesk. Model menyediakan manajemen masalah proaktif untuk mencari ide peningkatan layanan tetapi tidak menyediakan pencatatan ide peningkatan layanan.

Memberikan pelatihan dan petunjuk pada aplikasi pencatatan. Membuat pencatatat ide peningkatan layanan dan proses untuk meneruskan ide kepada tim terkait.

Kurangnya Configuration Management Database (CMDB) yang formal.

Model sudah memiliki Change Management System (CMS).

4.8.4

-

Manajemen masalah reaktif dan proaktif

Pada penelitian kannamani ditinjauan pustaka, pendekatan manajemen masalah menggunakan pendekatan manajemen reaktif dan proaktif. Pada manajemen reaktif ada 3 hal yang dibahas yaitu: 1. Aktivitas kendali masalah: meliputi analisis apakah insiden memiliki kemiripan dengan insiden lain yang sudah pernah ada. Hal ini sejalan dengan pembahasan pada 4.8.3 dimana menghasilkan saran membuat tautan antar insiden sehingga dapat diketahui bahwa insiden berulang.



88

2. Klasifikasi: meliputi mengidentifikasi tingkat kepentingan masalah dan menentukan sumber daya yang menangani. Pada model konseptual klasifikasi sudah ada dan mempengaruhi penanganan masalah. 3. Penyidikan dan diagnosa: meliputi pencarian akar masalah, pemberian rekomendasi solusi jangka pendek, dan pengelolaan known-error database. Pada model konseptual hal-hal tersebut sudah ada. Pada manajemen proaktif ada 2 hal yang dibahas yaitu: 1. Tren insiden: meliputi pemeriksaan laporan masalah dan insiden untuk mengetahui tren insiden dan masalah dan menegaskan adanya penanganan yang belum dilakukan secara tuntas. Pada model konseptual, pendeteksian tren insiden ini dilakukan pada manajemen masalah proaktif. 2. Aksi preventif: meliputi penentuan masalah-masalah potensial yang berdampak besar kepada bisnis. Aksi ini termasuk manajemen perubahan, pelatihan tim IT Helpdesk, dan rekomendasi perubahan prosedur. Pada model konseptual aksi ini belum ada dan dilengkapi pada manajemen masalah proaktif. Pada manajemen masalah reaktif dan proaktif, disarankan untuk menambahkan aksi preventif. 4.8.5

Perubahan yang diusulkan

Setelah membandingkan rekomendasi gap model konseptual dengan kesesuaian dengan budaya perusahaan, saran dari challenges implementasi ITIL, dan saran dari manajemen reaktif dan proaktif maka didapatkan usulan perubahan manajemen operasi layanan sebagai berikut: 1. Membuat generator notifikasi event kemudian menjalankan aktivitas mengelola generator notifikasi event. 2. Menjalankan aktivitas mengelola pemilahan event dan menjalankan aktivitas pengangan event. 3. Menambahkan sumber masuk insiden dari manajemen event. Universitas Indonesia


89

4. Melakukan pencatatan insiden setelah menerima insiden dan melakukan pengecekan apakah insiden yang bersifat major. 5. Menambahkan eskalasi hierarkis kepada manajemen. 6. Membuat manajemen masalah proaktif dan mengelolanya. Melakukan aksi preventif pada manajemen masalah proaktif, misalnya memberikan pelatihan dan petunjuk pada aplikasi pencatatan. 7. Menambahkan pendeteksian masalah yang berasal dari manajemen event, manajemen

masalah

proaktif,

dan

masalah

yang

berasal

dari

supplier/kontraktor. 8. Membuat pencatatan yang berbeda antara masalah dan insiden dan membuat tautan antar insiden sehingga dapat diketahui bahwa insiden berulang. 9. Membuat prioritas penanangan masalah. 10. Membuat CMS dan mengelola CMS kemudian menggunakan CMS dalam investigasi dan diagnosa. 11. Membuat known-error database dan mengelola known-error database kemudian menggunakan known-error database untuk mencari solusi jangka pendek. 12. Melakukan peninjauan efektivitas oleh tim IT Helpdesk. 13. Membuat pencatatan ide peningkatan layanan dan proses untuk meneruskan ide kepada tim terkait. 4.8.6

Perubahan yang diterima

Penulis melakukan focus group discussion (FGD) untuk menerima masukan dari tim IT Helpdesk dan IT Development Head dan menentukan perubahan yang akan dijalankan oleh IT Helpdesk dan menjadi proses manajemen operasi layanan yang baru. Berdasarkan dari lampiran-7 minutes of meeting, berikut adalah hasil dari FGD yang sudah dilakukan:



90

Tabel 4.7 Saran dari FGD untuk usulan perubahan Usulan perubahan Keputusan Komentar Membuat generator notifikasi event Ya, Implementasi teknis kemudian menjalankan aktivitas sebagian dibicarakan lebih lanjut. Saat ini IT Helpdesk lebih fokus mengelola generator notifikasi event. kepada alert dulu. Belum mengejar yang autoresponse. Menjalankan aktivitas mengelola Ya Penanganan dilakukan manual pemilahan event dan menjalankan dengan working instruction. aktivitas pengangan event. Menambahkan sumber informasi masuk insiden dari manajemen event. Melakukan pencatatan insiden setelah menerima insiden dan melakukan pengecekan apakah insiden yang bersifat major. Menambahkan eskalasi hierarkis dari IT Helpdesk ke manajemen.

Membuat manajemen masalah proaktif dan mengelolanya. Melakukan aksi preventif pada manajemen masalah proaktif, misalnya memberikan pelatihan dan petunjuk pada aplikasi pencatatan. Menambahkan pendeteksian masalah yang berasal dari manajemen event, manajemen masalah proaktif, dan masalah yang berasal dari supplier/kontraktor. Membuat pencatatan yang berbeda antara masalah dan insiden dan membuat tautan antar insiden sehingga dapat diketahui bahwa insiden berulang. Membuat prioritas penanangan masalah.

Ya

-

Ya

Akan dilakukan setelah ada dengan peralatan kerja.

Tidak

Ya

Masih khawatir keakuratan informasi masalah dan pemahaman masalah teknis di sisi manajemen. Eskalasi dilakukan manual melalui supervisor. Akan dilakukan setelah ada peralatan/tools yang memadai dan kategorisasi yang jelas.

Ya

Dilakukan setelah ada manajement event dan manajemen proaktif.

Ya

Sangat setuju.

Ya

Sangat setuju.



91 Tabel 4.7 Saran dari FGD untuk usulan perubahan (Sambungan) Usulan perubahan Keputusan Komentar Tidak Tidak dalam waktu dekat, Membuat CMS dan mengelola CMS karena penyusunan data CMS kemudian menggunakan CMS dalam investigasi dan diagnosa. awal yang memakan banyak waktu dan sumber daya, termasuk pengumpulan informasi dari departemen infrastuktur. Membuat known-error database dan Ya Ada pandangan untuk mengelola known-error database dibagikan kepada pengguna kemudian menggunakan knownuntuk error yang non teknis. error database untuk mencari solusi jangka pendek. Melakukan peninjauan efektivitas Ya Akan dilakukan apabila sudah penanganan oleh tim IT Helpdesk. ada peralatan/tools. Membuat pencatatan ide peningkatan layanan dan proses untuk meneruskan ide kepada tim terkait.

Ya

-

Setelah usulan perubahan direvisi dihadapan peserta FGD, dan kembali dilakukan diskusi antara para peserta FGD untuk mengetahui apakah ada perubahan usulan kembali terkait dengan hasil yang sudah disepakati. Hasil dari diskusi tersebut adalah bahwa usulan perubahan yang terkini sudah diterima. 4.9

Model manajemen operasi layanan Toyota Astra Finance

Sebagaimana yang ada pada pembahasan 4.8.6 bahwa semua usulan perubahan diterima kecuali: 1. Pada aktivitas mengelola pemilahan event tidak memanfaatkan proses autoresponse. Sehingga aktivitas pengelolaan manajemen event hanya dibatasi pada peringatan/alert untuk dilakukan intervensi manusia. 2. Penambahan eskalasi hierarkis dari IT Helpdesk ke manajemen. Sehingga eskalasi tetap dilakukan melalui supervisor. 3. Pengelolaan CMS dan penggunakan CMS dalam investigasi dan diagnosa masalah. Karena penyusunan data CMS awal yang memakan banyak waktu dan sumber daya. Dari hasil perubahan tersebut dihasilkan model dengan aktivitas sebagai berikut: Universitas Indonesia


92

Gambar 4.7 Model manajemen operasi layanan Toyota Astra Finance Ada satu aktivitas yang dihilangkan dari model konseptual yaitu “mengelola CMS”. Aktivitas “melakukan manajemen event” ada perubahan tetapi tidak menghilangkan aktivitas tersebut dari model. Aktivitas eskalasi mempengaruhi aktivitas “melakukan penanganan masalah” tetapi juga tidak menghilangkan aktivitas tersebut. 4.10 Proses-proses manajemen operasi layanan Toyota Astra Finance Berikut adalah penjabaran detil proses dari aktivitas dalam model manajemen operasi layanan Toyota Astra Finance. 1. Mengelola generator notifikasi event. TI membuat suatu sistem manajemen event yang menjadi generator notifikasi otomatis dari event-event yang terjadi, misalnya koneksi jaringan putus, server mati, penggunaan processor server yang tinggi, adanya aktivitas Universitas Indonesia


93

pengguna yang mencurigakan, dan sebagainya. Sistem manajemen event memantau system atau menerima respon dari system lain. Event dideteksi kemudian meneruskan notifikasi kepada agen. Sistem manajemen event mencatat semua event yang diteruskan kepada agen dan juga mencatat pilihan respon yang dilakukan oleh agen. 2. Mengelola pemilahan event Event yang diteruskan oleh sistem manajemen event diperiksa oleh agen apakah perlu direspon atau tidak. Jika tidak perlu direspon maka agen memilih untuk merespon bahwa event sudah diinformasikan tanpa ada respon yang perlu dilakukan. Jika perlu direspon maka agen menentukan apakah ini ditangani secara langsung atau dimasukan sebagai kategori insiden, masalah, atau permintaan untuk melakukan perubahan. Sistem manajemen event mencatat pilihan aksi agen tersebut. 3. Melakukan penanganan event Event yang dipilih untuk direspon secara langsung maka langsung dikerjakan oleh agen. Setelah selesai agen menuliskan aksi yang dilakukan pada manajemen event. Jika event diteruskan sebagai insiden, masalah, atau permintaan perubahan maka sistem manajemen event meneruskan informasi ke sistem yang lain. Status event tetap dalam proses penyelesaian sampai sistem lain memberikan umpan balik kepada manajemen event bahwa event yang diteruskan sudah selesai ditangani. Setelah event selesai ditangani baik diteruskan ke sistem lain atau ditangani agen langsung maka manajemen event memberikan notifikasi kepada agen untuk melakukan peninjauan apakah aksi yang diberikan efektif atau tidak. Jika tidak efektif maka respon pilihan kembali terbuka untuk dikerjakan kembali atau diteruskan ke sistem lain. Tetapi jika sudah selesai maka event diubah statusnya sebagai sudah selesai.



94

Gambar 4.8 Proses manajemen event



95

Proses pada gambar 4.8 hanya melibatkan satu peran saja. Apabila digambaran dalam Business Process Model Notation (BPMN) maka didapatkan gambar berikut.

Gambar 4.9 BPMN manajemen event 4. Menerima insiden yang masuk



96

Insiden yang masuk datang dari laporan pengguna baik telepon, SMS, surel, dan CDR atau URF dari aplikasi E-Dora. Selain itu insiden juga dapat datang dari sistem manajemen event sebagai mana dijelaskan pada nomor 3 diatas. Insiden kemudian di identifikasi dan dicatat kedalam suatu log dari sistem manajemen masalah. Insiden kemudian dicek apakah masuk kategori pemenuhan permintaan (request fulfilment), jika benar dan insiden bukan berasal dari URFA aplikasi E-Dora maka agen menginformasikan kepada pengguna untuk membuat URFA. Jika pengguna menyatakan sudah membuat maka agen mencari pada aplikasi E-Dora dan memberikan informasi bahwa permintaan dalam pengerjaan. Proses pemenuhan permintaan dilanjutkan apabila sesuai wewenang dan keahlian atau dieskalasi apabila memang diluar wewenang. Apabila insiden tidak termasuk dalam pemenuhan permintaan (request fulfilment) maka dilakukan pengecekan apakah masuk insiden major atau tidak. Jika insiden adalah major maka langsung dieskalasi kepada supervisor dan 2nd level dengan memberikan tanda insiden major dan jika bukan major maka dilakukan penangan insiden. 5. Melakukan penangan insiden Insiden diperiksa apakah memerlukan eskalasi fungsional atau hierarkis, apabila memerlukan eskalasi fungsional atau hierarkis maka dilakukan eskalasi ke supervisor. Agen IT Helpdesk/1st Level melalukan investigasi dan diagnosa insiden. Setelah diketahui penyebabnya kemudian dilakukan resolusi insiden dan pemulihan insiden. Jika insiden dieskalasi maka supervisor atau 2nd Level melakukan deteksi masalah. Apabila sudah selesai dilakukan penangan insiden maka insiden diubah statusnya sebagai sudah selesai oleh yang menangani insiden yaitu agen, supervisor, atau 2nd Level. Insiden yang datang datang dari manajemen event memicu sistem manajemen insiden untuk memberikan umpan balik kepada sistem manajemen event bahwa event sudah selesai ditangani.



97

Gambar 4.10 Proses manajemen insiden Universitas Indonesia


98

Untuk memperjelas proses yang dikelola antar peran berikut adalah gambar BPMN dari proses manajemen insiden.

Gambar 4.11 BPMN manajemen insiden 6. Mengelola manajemen masalah proaktif TI membuat suatu sistem manajemen masalah proaktif yang berisi laporan trend event, insiden, dan masalah yang terjadi. Supervisor menganalisa terkait tren dan masalah-masalah potensial yang berdampak besar kepada bisnis (aksi preventif) sebagai inisiatif perbaikan. Sistem manajemen masalah dapat Universitas Indonesia


99

menerima inisiatif-inisatif yang ditemukan sebagai bagian dari peningkatan layanan yang berkelanjutan. Sistem manajemen masalah proaktif ini meneruskan inisiatif sebagai masalah di manajemen masalah dan menanti umpan balik dari manajemen masalah.

Gambar 4.12 Proses manajemen masalah proaktif

Gambar 4.13 BPMN manajemen masalah proaktif Universitas Indonesia


100

7. Mendeteksi masalah Agen masalah terdeteksi masalah yang masuk dari laporan pengguna melalui manajemen insiden, dari sistem manajemen event, dari manajemen masalah proaktif,

maupun

masalah

dari

supplier/kontraktor.

Masalah

dari

supplier/kontraktor langsung dimasukan ke sistem manajemen masalah oleh tim IT Helpdesk. 8. Melakukan penanganan masalah Masalah yang masuk ke sistem manajemen masalah dikategorisasi dan diberi prioritas penanganan. Masalah selanjutnya dilakukan investigasi dan diagnosa serta mencari tahu apakah masalah yang muncul sudah pernah ada pada known-error database. Jika belum ada pada known-error database dan ditemukan solusi jangka pendek/workaround maka dicatat pada known-error database. Apabila diperlukan solusi jangka panjang yang memerlukan perubahan maka perubahan di sistem maka perubahan dikerjakan oleh 2nd level atau vendor (jika perlu diteruskan ke vendor) dengan status “dalam proses” sampai solusi jangka panjang diterapkan. Setelah ada solusi jangka panjang maka masalah kemudian diubah statusnya menjadi “selesai”.



101

Gambar 4.14 Proses manajemen masalah Universitas Indonesia


102

Gambar 4.15 BPMN manajemen masalah 9. Mengelola known-error database TI membuat suatu known-error database. Semua masalah atau error yang sudah diketahui solusi jangka pendeknya dicatat pada basisdata ini. Solusi Universitas Indonesia


103

jangka pendek yang ada dapat diperbaharui oleh tim IT Helpdesk yang sedang melakukan penanganan jika solusi lain yang lebih efektif dan efisien. 10. Meninjau efektivitas penanganan Dilakukan peninjauan efektivitas penangan oleh tim IT Helpdesk atas Masalah dengan keterangan sebagai masalah major. Peninjauan juga dilakukan untuk event, dan insiden yang dianggap signifikan. Tim IT Helpdesk juga melakukan peninjauan mengenai event dan masalah yang tidak tertangani dengan efektif dan efisien dengan data secara otomatis dari catatan sistem. 11. Monitor/Mengawasi IT Development Head melakukan pengawasan kinerja IT Helpdesk dengan menggunakan kriteria pengukuran performa berupa: a. Survei ke dalam organisasi: o Efficacy: Apakah dukungan layanan TI memuaskan? o Effectiveness: Apakah pemenuhan permintaan dukungan layanan TI membuat operasional bisnis tidak terganggu oleh hal-hal terkait TI? b. Laporan dari sistem: o Efficiency: Jumlah permintaan dukungan layanan TI yang terpenuhi. o Efficiency: Penggunaan sumber daya IT Helpdesk digunakan dalam memberikan pemenuhan permintaan dukungan layanan TI dari pengguna. 12. Mengambil tindakan Manajemen mengambil tindakan untuk melakukan perbaikan/meningkatan operasi layanan IT Helpdesk berdasarkan hasil pengawasan kinerja IT Helpdesk.



104

4.11 Usulan Tools Dari semua proses yang dibahas pada 4.10 maka didapatkan beberapa fitur yang harus dimiliki oleh tools IT Helpdesk sebagai berikut: Tabel 4.8 Tabel fitur aplikasi helpdesk Sistem Manajemen event Manajemen event Manajemen event Manajemen event Manajemen event Manajemen event Manajemen insiden Manajemen insiden Manajemen insiden Manajemen insiden Manajemen insiden Manajemen insiden Manajemen masalah proaktif Manajemen masalah proaktif Manajemen masalah proaktif Manajemen masalah proaktif Manajemen masalah Manajemen masalah Manajemen masalah Manajemen masalah Manajemen masalah Manajemen masalah Known-Error Database Known-Error Database Manajerial report

Fitur Mendeteksi event Memberikan notifikasi kepada agen Menerima umpan balik dari sistem lain Mentransfer informasi event ke sistem lain Melakukan pencatatan event dan aksi agen Meminta agen untuk melalukan peninjauan efektivitas penanganan Mencatat insiden yang masuk Menerima umpan balik dari sistem lain Mentransfer informasi ke sistem lain Memisahkan insiden berdasarkan kategori dan tingkat majority Melakukan eskalasi kepada supervisor/2nd level Mencatat penanganan insiden yang dilakukan Memberikan laporan trend event / insiden / masalah Menerima inisiatif dari tim IT Helpdesk Menerima umpan balik dari sistem lain Mentransfer informasi event ke sistem lain Menerima umpan balik dari sistem lain Mentransfer informasi event ke sistem lain Melakukan pencatatan masalah Memberikan kategori dan prioritas masalah Melakukan eskalasi kepada 2nd level/vendor Mencatat penanganan masalah yang dilakukan Mencatat error dan resolusi yang ada Melakukan pencarian error dan resolusi Memberikan laporan-laporan kinerja IT Helpdesk kepada manajerial



105

Penulis mengusulkan untuk menggunakan aplikasi open source berbasis web “Redmine”. Lesyuk (2013) menjelaskan bahwa Redmine adalah aplikasi manajemen proyek gratis berbasis web yang cukup popular dan ditulis dalam Ruby on Rail. Redmine juga dikenal sebagai aplikasi issue tracker yang mendukung pemberian prioritas, sub issue, komentar, monitoring, custom field, filter dan lain-lain. Berikut adalah tabel kesesuian fitur yang dibutuhkan dengan aplikasi Redmine dimana Redmine sudah memenuhi sebagian besar kebutuhan. Tabel 4.9 Tabel kesesuaian fitur aplikasi Redmine Sistem Manajemen event Manajemen event Manajemen event Manajemen event Manajemen event Manajemen event Manajemen insiden Manajemen insiden Manajemen insiden Manajemen insiden Manajemen insiden Manajemen insiden Manajemen masalah proaktif Manajemen masalah proaktif Manajemen masalah proaktif

Fitur Mendeteksi event Memberikan notifikasi kepada agen

Komentar Belum ada, perlu ditambahkan modifikasi Ada

Menerima umpan balik dari sistem lain Mentransfer informasi event ke sistem lain Melakukan pencatatan event dan aksi agen Meminta agen untuk melalukan peninjauan efektivitas penanganan Mencatat insiden yang masuk

Belum ada, perlu ditambahkan modifikasi Ada

Menerima umpan balik dari sistem lain Mentransfer informasi ke sistem lain

Belum ada, perlu ditambahkan modifikasi Ada

Memisahkan insiden berdasarkan kategori dan tingkat majority Melakukan eskalasi kepada supervisor/2nd level Mencatat penanganan insiden yang dilakukan Memberikan laporan trend event / insiden / masalah

Ada

Ada Ada Ada

Ada Ada Ada

Menerima inisiatif dari tim IT Helpdesk

Ada

Menerima umpan balik dari sistem lain

Belum ada, perlu ditambahkan modifikasi



106 Tabel 4.9 Tabel kesesuaian fitur aplikasi Redmine (Sambungan) Komentar Sistem Fitur Manajemen Mentransfer informasi event ke sistem Belum ada, perlu lain masalah ditambahkan modifikasi proaktif Manajemen Menerima umpan balik dari sistem Ada masalah lain Manajemen Mentransfer informasi event ke sistem Ada masalah lain Manajemen Melakukan pencatatan masalah Ada masalah Manajemen Memberikan kategori dan prioritas Ada masalah masalah Manajemen Melakukan eskalasi kepada 2nd Ada masalah level/vendor Manajemen Mencatat penanganan masalah yang Ada masalah dilakukan KnownMencatat error dan resolusi yang ada Ada Error Database KnownMelakukan pencarian error dan Ada Error resolusi Database Manajerial Memberikan laporan-laporan kinerja Ada report IT Helpdesk kepada manajerial

4.12 Usulan SOP Dari proses yang sudah dibuat pada 4.10 maka penulis mengusulkan Standard Operating Procedure (SOP) sebagai berikut: 4.12.1 Draft SOP Manajemen Event IT Helpdesk 1. Tujuan Standard Operating Procedure (SOP) ini dimaksudkan untuk memberikan panduan pada proses penanganan event di IT Helpdesk agar tercipta tertib administrasi dalam pelaksanaan prosedur penanganan event. Dengan berlakunya SOP ini, maka diharapkan dapat menciptakan kontrol yang baik pada penanganan event pada bagian IT Helpdesk. 2. Ruang lingkup a. Prosedur ini berlaku pada bagian IT Helpdesk. b. Prosedur ini meliputi penanganan event pada IT Helpdesk. 3. Definisi Universitas Indonesia


107

a. Event : Kejadian yang muncul dan berpotensi menggangu operasional layanan TI baik infrastruktur jaringan maupun aplikasi. 4. Dasar Kebijakan a. Gangguan layanan TI diselesaikan oleh tim dari Divisi IT sebagai pemilik dari layanan TI terkait dengan infrastruktur jaringan, sistem server, dan aplikasi. 5. Dokumen 6. Diagram Prosedur Manajemen Event IT Helpdesk

Gambar 4.16 SOP Manajemen Event IT Helpdesk Universitas Indonesia


108

4.12.2 Draft SOP Manajemen Insiden IT Helpdesk 1. Tujuan Standard Operating Procedure (SOP) ini dimaksudkan untuk memberikan panduan pada proses penanganan insiden di IT Helpdesk agar tercipta tertib administrasi dalam pelaksanaan prosedur penanganan insiden. Dengan berlakunya SOP ini, maka diharapkan dapat menciptakan kontrol yang baik pada penanganan insiden pada bagian IT Helpdesk. 2. Ruang lingkup a. Prosedur ini berlaku pada bagian IT Helpdesk. b. Prosedur ini meliputi penanganan insiden pada IT Helpdesk. 3. Definisi a. Insiden: Permintaan dari user baik berupa permintaan informasi, laporan terkait permasalahan TI, dan permintaan dalam bentuk formulir elektronik yang muncul. 4. Dasar Kebijakan a. Permintaan layanan TI dikerjakan oleh tim dari Divisi IT sebagai pemilik dari layanan TI terkait dengan infrastruktur jaringan, sistem server, perubahan aplikasi, dan manajemen akses. 5. Dokumen a. Tidak ada 6. Diagram Prosedur Manajemen insiden IT Helpdesk



109

Gambar 4.17 SOP Manajemen Insiden IT Helpdesk (1) Universitas Indonesia


110

Gambar 4.18 SOP Manajemen Insiden IT Helpdesk (2) Universitas Indonesia


111

Gambar 4.19 SOP Manajemen Insiden IT Helpdesk (3) 4.12.3 Draft SOP Manajemen Masalah Proaktif IT Helpdesk 1. Tujuan Standard Operating Procedure (SOP) ini dimaksudkan untuk memberikan panduan pada proses manajemen masalah proaktif di IT Helpdesk agar menjaga budaya continous improvement pada Toyota Astra Finance. Dengan berlakunya SOP ini, maka diharapkan dapat menciptakan inisatif-inisatif perbaikan pada penanganan insiden di bagian IT Helpdesk. 2. Ruang lingkup a. Prosedur ini berlaku pada bagian IT Helpdesk. b. Prosedur ini meliputi manajemen masalah proaktif pada IT Helpdesk. Universitas Indonesia


112

3. Definisi Tidak ada 4. Dasar Kebijakan a. Budaya continous improvement (Kaizen) di perusahaan merupakan hal yang terus digalakan melalui Corporate Planning and Improvement Department ke semua departement dan cabang. Begitu juga dengan pengelolaan IT Helpdesk, permintaan layanan TI dikerjakan oleh tim dari Divisi IT sebagai pemilik dari layanan TI harus terus mengalami peningkatan dan perbaikan. 5. Dokumen a. Tidak ada 6. Diagram Prosedur Manajemen masalah proaktif IT Helpdesk

Gambar 4.20 SOP Manajemen Masalah Proaktif 4.12.4 Draft SOP Manajemen Masalah IT Helpdesk 1. Tujuan Standard Operating Procedure (SOP) ini dimaksudkan untuk memberikan panduan pada proses penanganan masalah di IT Helpdesk agar tercipta tertib administrasi dalam pelaksanaan prosedur penanganan masalah. Dengan berlakunya SOP ini, maka diharapkan dapat menciptakan kontrol yang baik pada penanganan masalah pada bagian IT Helpdesk. 2. Ruang lingkup a. Prosedur ini berlaku pada bagian IT Helpdesk. Universitas Indonesia


113

b. Prosedur ini meliputi penanganan masalah pada IT Helpdesk. 3. Definisi Tidak ada 4. Dasar Kebijakan a. Masalah pada layanan TI diselesaikan oleh tim dari Divisi IT sebagai pemilik dari layanan TI terkait dengan infrastruktur jaringan, sistem server, dan aplikasi. 5. Dokumen a. Tidak ada 6. Diagram Prosedur Manajemen Masalah IT Helpdesk



114

Gambar 4.21 SOP Manajemen Masalah IT Helpdesk (1)



115

Gambar 4.22 SOP Manajemen Masalah IT Helpdesk (2) 4.13 Usulan Metrik Pengukuran Efektivitas dan Efisiensi Sebagaimana yang dijelaskan pada tinjauan pustaka pada 2.4.1, OGC (2007) memberikan beberapa rekomendasi untuk mengukur efektivitas dan efisisiensi dari operasi layanan dengan menggunakan beberapa metrik. Penulis mengusulkan metrik-metrik yang ada pada rekomendasi tinjauan pustaka 2.4.1 tetapi ada metrik yang dihilangkan pada usulan yaitu "Jumlah dan persentase Universitas Indonesia


116

dari event yang membutuhkan intervensi manusia dan jumlah yang ditangani" karena sesuai dengan hasil FGD Toyota Astra Finance tidak menggunakan Auto Response pada manajemen event. Kemudian ditambahkan juga metrik untuk mengukur manajemen masalah proaktif dan ditambahkan metrik Efficacy, dan Effectiveness dari pembahasan 4.10. Tabel 4.10 Tabel metrik pengukuran efektivitas dan efisiensi operasi layanan Aktivitas yang diukur Manajemen Event Manajemen Event Manajemen Event

Metrik Jumlah event per kategori. Jumlah event per signifikansi. Jumlah dan persentase dari event yang membutuhkan intervensi manusia dan jumlah yang ditangani.

Manajemen Event

Jumlah dan persentase event yang mengakibatkan insiden atau perubahan.

Manajemen Event

Jumlah dan persentase event yang diakibatkan masalah yang sudah ada atau known-error.

Manajemen Event Manajemen Event

Jumlah dan persentase dari event yang berulang atau terduplikasi. Jumlah dan persentase dari event yang mengindikasikan isu kinerja. Jumlah dan persentase dari event yang mengindikasikan potensi isu ketersediaan.

Manajemen Event Manajemen Event Manajemen Event Manajemen Insiden Manajemen Insiden Manajemen Insiden Manajemen Insiden Manajemen Insiden Manajemen Insiden

Jumlah dan persentase dari tiap event per platform atau aplikasi. Jumlah dan rasio event dibandingkan dengan jumlah insiden. Total jumlah insiden. Total Insiden yang didetailkan pada status insiden. Jumlah insiden saat ini yang backlog. Jumah dan persentase insiden major. Rata-rata waktu yang dibutuhkan untuk mencapai resolusi insiden. Persentase insiden yang ditangani yang masih didalam waktu respon yang disepakati.

Manajemen Insiden Manajemen Insiden

Biaya rata-rata per insiden. Jumlah insiden yang terbuka kembali (reopened) dibandingkan dengan persentase total.

Manajemen Insiden

Jumlah dan persentase insiden yang tidak ditugaskan dengan benar. Jumlah dan persentase insiden yang memiliki kategori yang tidak tepat.

Manajemen Insiden Manajemen Insiden

Persentase insiden yang diselesaikan tanpa eskalasi (first point contact). Universitas Indonesia


117 Tabel 4.10 Tabel metrik pengukuran efektivitas dan efisiensi operasi layanan (Sambungan) Aktivitas yang Metrik diukur Manajemen Insiden Jumlah dan persentase insiden yang diproses per agen. Manajemen Insiden Jumlah dan persentase insiden yang diselesaikan tanpa perlu kunjungan ke lokasi. Manajemen Insiden

Jumlah insiden per waktu dalam sehari untuk mengetahui puncak beban dan meastikan sumber daya mencukupi.

Manajemen Masalah Manajemen Masalah Manajemen Masalah

Jumlah total masalah yang tercatat dalam suatu periode. Persentase masalah yang diselesaikan dalam target SLA. Jumlah dan persentase masalah yang melebihi target waktu resolusi. Jumlah backlog masalah dan trend masalah. Rata-rata biaya penanganan masalah. Jumlah masalah major. Persentase dari peninjauan masalah major yang berhasil dilakukan. Jumlah Known-Error yang ditambahkan ke dalam Kown-Error Database.

Manajemen Masalah Manajemen Masalah Manajemen Masalah Manajemen Masalah Manajemen Masalah Manajemen Masalah Manajemen Masalah

Persentase akurasi dari Kown-Error Database. Persentase peninjauan masalah major yang selesai dilakukan dan tepat waktu.

Pemenuhan Permintaan Pemenuhan Permintaan Pemenuhan Permintaan Pemenuhan Permintaan

Jumlah permintaan layanan.

Pemenuhan Permintaan

Jumlah dan persentase permintaan layanan yang selesai dalam batas waktu yang disepakati.

Pemenuhan Permintaan Pemenuhan Permintaan

Rata-rata biaya per permintaan layanan.

Manajemen Akses Manajemen Akses Manajemen Akses

Jumlah permintaan akses. Akses yang diberikan per pengguna dan departemen. Akses yang diberikan oleh departemen atau pemberian akses individual.

Manajemen Akses Manajemen Akses Manajemen Masalah Proaktif

Jumlah insiden yang membutuhkan reset hak akses. Jumlah insiden yang disebabkan kesalahan pemberian akses. Jumlah inisatif yang dicatat dalam suatu periode

Permintaan layanan pada tiap tahap. Jumlah backlog saat ini. Waktu rata-rata penyelesaian penanganan tiap jenis permintaan layanan.

Tingkat kepuasan pelanggan dari penanganan permintaan melalui survei.



118 Tabel 4.10 Tabel metrik pengukuran efektivitas dan efisiensi operasi layanan (Sambungan) Aktivitas yang diukur Manajemen Masalah Proaktif Efficacy Effectiveness

Metrik Jumlah inisatif yang berhasil diterapkan Kepuasan dukungan layanan TI melalui survei Jumlah gangguan layanan TI yang menghambat operasional bisnis

4.14 Analisis Dampak Dampak yang didapatkan oleh organisasi dengan mengimplementasi manajemen operasi layanan yang baru adalah: 1. Meningkatkan performa IT Helpdesk Dengan menerapkan manajemen operasi layanan yang baru maka event yang terjadi dapat dideteksi lebih cepat tanpa harus menunggu adanya keluhan pengguna. Hal mempercepat proses penanganan event yang muncul karena hilangnya jeda waktu antara kejadian sampai pengguna melaporkan event atau insiden. Selain itu adanya optimasi proses-proses seperti penggunaan known-error database dapat mempersingkat waktu dalam melakukan penanganan masalah. 2. Meningkatkan kepuasan pengguna layanan TI Dengan adanya manajemen masalah proaktif maka IT Helpdesk dapat mengetahui dan memprediksi adanya masalah sehingga masalah dapat segera ditangani. Apabila masalah-masalah selesai sebelum ditemui oleh pengguna maka pengguna akan lebih yakin atas keandalan layanan-layanan TI. 3. Pelaporan kepada manajemen yang lebih akurat Manajemen operasi layanan yang baru dapat memisahkan antara insiden berulang dari suatu masalah sehingga manajemen dapat melihat secara unik masalah-masalah apa yang muncul dan frekuensi insiden dari masalah itu. Manajemen juga dapat membaca trend insiden dan melakukan analisa apakah penanganan yang sudah diberikan IT Helpdesk efektif atau tidak.



119

Adanya proses-proses yang baku memudahkan manajemen untuk melakukan monitoring atas performa tiap-tiap proses dan dapat membantu dalam menetapkan suatu SLA dari penanganan insiden atau masalah berdasarkan kategori dan prioritas insiden atau masalah tersebut. Penerapan best practice ITIL v3 dalam suatu organisasi diikuti oleh penerimaan dari organisasi tersebut terkait dengan kebijakan dan budaya organisasi. Penelitian ini membantu menunjukan bagaimana manajemen operasi layanan pada ITIL v3 dapat diserap sesuai dengan budaya organisasi masing-masing. Organisasi dengan budaya dan kebijakan yang berbeda dapat saja menerapkan best practice ITIL v3 sesusai dengan penerimaan organisasi tersebut dengan tetap mendapatkan keuntungan dari penerapan best practice tersebut.



BAB 5 KESIMPULAN DAN SARAN

Bab ini menjabarkan kesimpulan dan saran dari penelitian yang sudah dilakukan. Bagian kesimpulan berisi jawaban dari pertanyaan penelitian berdasarkan hasil yang sudah diperoleh. Bagian saran akan berisi penjelasan hal-hal yang sebaiknya dilakukan untuk penelitian sejenis dikemudian hari dan saran untuk penelitian berikutnya dari tidak lanjut penelitian ini. 5.1

Kesimpulan

Seperti penjabaran pada 1.3 telah disampaikan pertanyaan penelitian “Bagaimana manajemen operasi layanan IT Helpdesk di PT Toyota Astra Financial Services?” dengan tujuan untuk menjadi panduan bagi IT Helpdesk dalam memberikan operasi layanan-layanan TI di PT Toyota Astra Financial Services dan meningkatkan kualitas operasi layanan-layanan yang diberikan oleh IT Helpdesk di PT Toyota Astra Financial Services. Dengan menerapkan kerangka teoritis, metodologi penelitian, best practice operasi layanan ITIL v3, dan pengetahuan terkait organisasi sebagai acuan dalam melakukan analisis, maka berikut uraian kesimpulan penelitian ini: 1. Manajemen operasi layanan IT Helpdesk mencakup manajemen event, manajemen insiden, dan manajemen masalah. Pada manajemen event notifikasi event diberikan kepada tim IT Helpdesk untuk diintervensi dan ditangani. Event yang masuk dapat diteruskan kepada proses manajemen yang lain atau ditangani langsung. Penanganan event juga dilakukan peninjuan terkait efektivitas penangan. 2. Pada manajemen insiden agen menerima insiden dari berbagai sumber yaitu laporan pengguna, formulir dari sistem penanganan permintaan, dan manajemen Event. Insiden yang masuk diberikan prioritas yaitu perbedaan penangaan insiden major dengan yang tidak, diberikan eskalasi fungsional, hingga akhirnya insiden dinyatakan selesai ditangani. 120



121

3. Pada manajemen masalah dilakukan penanganan masalah dengan diberikan kategori, prioritas, dan dilakukan penanganan yang meliputi solusi jangka pendek, pemanfaatan known-error database, solusi jangka panjang yang diteruskan ke manajemen perubahan, dan meninjauan masalah yang bersifat major. 5.2

Saran

Berdasarkan proses yang dijalani dalam penelitian ini, maka penulis memberikan beberapa saran sebagai berikut: 1. Penelitian melibatkan fase operasi layanan pada ITIL v3 untuk memenuhi keefektifan dan efisiensi dalam menyediakan dan memberikan layanan dalam menjamin nilai/value yang diberikan kepada pengguna dan penyedia layanan. Menurut Bon (2007), agar manajemen layanan dapat menjadi suatu sumber daya strategis maka perlu dilibatkan fase ITIL v3 yang lain seperti fase perencanaan layanan. 2. Sebagaimana rekomendasi OCG (2007) pada landasan teori terkait dengan pembagian fungsi pada organisasi service desk, penulis menyarankan agar proses yang terkait dengan fungsi lain seperti Technical Management, Application Management, dan IT Operation Management dipisahkan dari iCare yang berfungsi sebagai Service Desk/IT Helpdesk agar ICare dapat berkerja secara efektif dan efisien serta sesuai dengan fungsi yang seharusnya. 3. Sebagai tindak lanjut dari penelitian ini, dapat dilakukan penelitian lanjut terkait dengan manajemen sumber daya manusia IT Helpdesk untuk melakukan peningkatan layanan dari sisi sumber daya manusia agar mendapatkan peningkatan layanan IT Helpdesk.



122

DAFTAR PUSTAKA

Addy, R. (2007). Effective IT Service Management: To ITIL and Beyond! New York: Springer-Verlag Berlin Heidelberg. Bader, G. E., & Rossi, C. A. (2002). Focus Groups: A Step-by-Step Guide (3rd Edition). San Diego: The Barder Group. Beisse, F. (2013). A Guide to Customer User Support for Help Desk and Support Specialist – Fifth Edition. Boston: Course Technology, Cengage Learning. Bon, J. v. (2007). Foundation of IT Service Management Based on ITIL V3. Zaltbommel: Van Haren Publishing. Federal Emergency Management Agency. (1999). Developing Effective Standard Operating Procedures For Fire and EMS Departments. USA: IOCAD Emergency Services Group. IT Governance Institute. (2011). Global Status Report on the Governance of Enterprise It (GEIT)—2011. Illinois: IT Governance Institute. Jackson, M. C. (2003). System Thinking: Creative Holism for Managers. England: John Wiley & Sons, Ltd. Jäntti, M. (2012). Examining Challenges in IT Service Desk System and Processes: A Case Study. ICONS 2012: The Seventh International Conference on System , 108. Jäntti, M. (2012). Towards an Improved IT Service Desk System and Processes: A Case Study. International Journal on Advances in Systems and Measurements, vol 5 no 3 & 4 , 203. Kannamani, R. (2013). Effective Implementation of Problem Management in ITIL Service Management. International Journal of Scientific & Engineering Research Volume 4, Issue 1 , 1. Lesyuk, A. (2013). Mastering Redmine. Birmingham: Pack Publishing. Universitas Indonesia


123

Office of Government Commerce. (2007). ITIL: Service Operation. Edinburgh: TSO (The Stationery Office). Prasanna, K. (2013). Standard Operating Procedures for Standalone Hotels. Research Journal of Management Sciences , 1. Sekaran, U. (2003). Research Methods for Business: A Skill Building Approach Fouth Edition. San Francisco: John Willey & Sons, Inc. TAFinance. (2014, 01 05). About TA Finance. Dipetik 01 05, 2015, dari Toyota Astra Finance: https://www.tafinance.com/about/index/about-ta-finance Wireman, T. (2003). Benchmarking Best Practices in Maintenance Management. New York: Industrial Press Inc. Wyoming Department of Environmental Quality. (2011). Manual of Standard Operating Procedures for Sample Collection and Analysis. Wyoming: Wyoming Department of Environmental Quality. Yin, R. K. (2011). Qualitative Research From Start To Finish. New York: The Guildford Press.



LAMPIRAN Lampiran 1 Transkrip Wawancara Dengan IT Development Head Narasumber

: TSU

Jabatan Narasumber : IT Development Department Head PT Toyota Astra Financial Service Tanggal Wawancara : 17 Maret 2014 Tempat Wawancara : Head Office PT Toyota Astra Financial Service

Penulis

: Selamat sore, perkenalkan saya Bayu Kusuma Wijaya dari Magister Teknik Informatika UI. Mau Minta waktunya sebentar pak untuk wawancara. Bisa?

Narasumber : Silakan Bayu Penulis

: Bisa minta sebutkan nama dan jabatan di Toyota Astra Finance pak ?

Narasumber : Nama saya TSU, jabatan saya sebagai IT Development Departement Head. Dimana saya bertanggung jawab dalam pengembangan sistem aplikasi di Toyota Astra Finance. Penulis

: Oke, Bisa diceritakan pak sekilas Tentang Toyota Astra Finance

Narasumber : Toyota Astra Finance adalah perusahaan pembiayaan yang berfokus pada kendaraan Toyota. Dimana Toyota Asra Finance ini sendiri merupakan joint venture company antara Toyota Jepang dan Astra International. Keberadaan Toyota Astra Finance di Indonesia sebagai value chain untuk memberikan totalitas layanan Toyota kepada customer. Sehingga customer bisa menikmati mobil Toyota mulai dari dealer Toyota, pembiayaan dari Toyota, sampai asuransinya itu juga dari Toyota. Penulis

: Seberapa tinggi pak pemanfaatan sistem informasi di Toyota Astra Finance

Narasumber : Pemanfaatan sistem informasi dalam hal ini IT System Aplikasi sangat tinggi, seperti layaknya industri keuangan yang lain. Dimana kami memiliki ulangi harus memiliki Sistem Informasi yang akurat, 124



125 (Lanjutan)

kredibel, dan setiap tahun kami akan mengalami proses audit untuk menjamin bahwa segala proses transaksi keuangan yang dilakukan dalam Toyota Astra Finance dapat dipertanggung jawabkan dan jelas. Penulis

: Aplikasi apa saja pak yang dipergunakan di Toyota Astra Finance.

Narasumber : Ada aplikasi untuk core system kami yang melayani mulai dari pembelian, pelayanan ke customer, sampai dengan proses collection handling. Begitu juga dengan aplikasi terhadap back-end system kami. Mulai dari Finance, Accounting, sampai dengan CRM kami. Penulis

: Jika ada terkait dengan sistem informasi, pengguna harus meminta bantuan kemana pak?

Narasumber : Dalam hal ini user bisa menghubungi iCare, yaitu IT Helpdesk kami. Penulis

: Ketergantungan operasional sehari-hari Toyota Astra Finance ke helpdesk ini setinggi apa pak?

Narasumber : Toyota Astra Finance sendiri memiliki jumlah user melebihi 700 user. Dan jika dibandingkan dengan jumlah problem atau request yang masuk kedalam iCare sekitar 1800 setiap bulannya, maka tingkat ketergantungan user terhadap dukungan iCare sangat tinggi. Penulis

: Yang diharapkan dari layanan helpdesk ini apa aja pak?

Narasumber : Sebetulnya kondisi ideal dari suatu helpdesk seperti perusahaanperusahaan IT lainnya, seharusnya agen bisa memisahkan kategori dimana problem yang critical, kemudian problem mana yang masih ada alternatif atau solusi jawaban lainnya, atau problem yang bahkan itu terjadinya intermitten atau sesekali. Dan harapannya dalam setiap problem kategori tersebut kami memiliki standard waktu pelayanan yang mendukung. Sebagai contoh, kondisi idealnya kami bisa mengidentifikasi problem ini apakah termasuk kedalam kategori vital yaitu stopper, user tidak dapat melanjutkan pekerjaanya dia, apakah itu karena error atau apakah ada kesalah operasional, dimana kami harus memberikan jaminan ke user bahwa dalam waktu kurang dari 8 jam problem tersebut harus segera solved. Atau kemudian ada Universitas Indonesia


126 (Lanjutan)

problem dengan kategori high, yaitu problem dimana user mengalami masalah namun masih ada alternatif lain untuk menyelesaikan proses tersebut. Sehingga untuk problem dengan kategori high mungkin IT masih bisa memberikan janji layanan kurang dari 2 hari. Itu adalah kondisi ideal yang kami harapkan di luar dari bahwa segala macam problem, request, itu akan masuk sebagai dan jelas PIC IT siapa yang mengerjakannya. Penulis

: Untuk kondisi yang saat ini di iCare itu seperti apa pak?

Narasumber : Kondisi saat ini di iCare kami baru ada pencatatan untuk setiap request yang masuk, beserta dengan PIC yang menanganinya dan status terakhir dari request/problem tersebut, apakah masih open, apakah in progress, apakah sudah closed. Namun kondisi ideal seperti yang tadi disebutkan masih ada gap. Karena kami masih belum bisa meng-identify jenis problem seperti apa atau bahkan kami juga belum bisa memberikan janji berapa waktu layanan yang dibutuhkan oleh user, berapa waktu layanan yang diberikan oleh IT untuk menjawab problem dari user. Penulis

: Oke Pak, jadi kalau boleh saya rangkum di helpdesk ini ketergantungannya cukup tinggi tapi disisi lain diharapkan helpdesk ini bisa merespon terhadap beberapa jenis kategori problem dengan cepat yaitu sekitar 8 jam atau 2 hari tergantung dengan jenis problem-nya tetapi saat ini belum bisa dilakukan karena masih melakukan monitoring-nya secara manual dan belum panduan pasti tentang service yang harus diberikan kepada pengguna.

Narasumber : Iya Penulis

: Oke, Terima kasih banyak Pak TSU atas waktunya

Narasumber : Terima kasih bayu



127

Lampiran 2 Transkrip Wawancara Dengan agen IT Helpdesk Narasumber

: DRO

Jabatan Narasumber : IT Helpdesk Support PT Toyota Astra Financial Service Tanggal Wawancara : 15 November 2014 Tempat Wawancara : Kantor Cabang Kelapa Gading PT Toyota Astra Financial Service

Id I-1

Ide

R-1 I-2 R-2

2 2

I-3 R-3

1 1

I-4 R-4

1 1

I-5 R-5 I-6 R-6

1 1 1 1

I-7 R-7

1 1

Transkrip wawancara Halo, Selamat siang Pak DRO, Saya Bayu dari Magister Teknik Informatika UI, mau tanya-tanya sebentar terkait dengan proses di TI help desk di Toyota Astra Finances atau biasa yang disebut iCare. Boleh minta waktunya sebentar Pak DRO? Oke boleh ya Pak Bayu, selamat siang nama saya DRO dari iCare. Ada yang bisa dibantu silahkan ditanyakan. Di iCare posisinya Pak DRO sebagai apa Pak? Saya sebagai IT Helpdesk support. kalau dibilang di iCare itu kita sebagai first level-nya sih. Di iCare permintaan yang masuk itu apa saja Pak DRO? Biasanya ada 3 permintaan yang masuk ke iCare itu biasanya request, informasi dan problem Request itu maksudnya gimana Pak? Request biasanya user banyak yang minta ke kita. terkait kalau request misalnya dia tidak bisa masuk ke PC atau login ke Confins itu biasanya kita bilang unlocked user. nah itu sebagai request. ada juga yang kadang-kadang user minta untuk, ada asuransi dari customer yang tidak bisa dicetak di cabang, nanti kita yang kirimin, kita cek dulu di database server, kita kirim langsung ke cabang. biasanya begitu. Itu Berarti semacam permintaan bantuan gitu ya Pak? Iya. Oke, Kalau infomasi Pak? Kalau informasi biasanya banyak user yang tanya, ada problem, apa namanya, ada “kenapa confins gak bisa di akses sekarang ya Pak?” “apakah ada maintenance atau apa?” nah kita biasa langsung memberikan infomasi terkait misalnya confins sedang memang ada maintenance Pak, jadi kita informasikan ke user. Biasanya sih seperti itu. Kalau problem? Problem, biasanya kalau terkait di confins ada aplikasi error ya, Universitas Indonesia


128 (Lanjutan)

Id

Ide

I-8 R-8 I-9 R-9

3 3

I-10

3

R-10 I-11

3 4

R-11

4

I-12 R-12 I-13

5

R-13

5

I-14

5

R-14 I-15

Transkrip wawancara misalnya setelah maintenance, user ada aplikasi, naikin aplikasi kadangkadang dia nyangkut aplikasinya, nah kita bantu problemnya itu. Biasanya sih kita re-run sih. ada workflow-workflow-nya, kita re-run aplikasinya, nanti dia bisa naik lagi langsung. Ehmm. Begitu berarti ada 3 jenis? Iya lalu permintaan-permintaan tadi itu masuknya melalui apa saja Pak? Biasanya sih user ada, yang paling banyak request eh apa namanya, problem-nya. Nah, itu biasanya lewat email, telepon dan juga mobile phone. Mobile phone kita itu biasanya sih buat user-nya gak telepon lagi ya, biasanya SMS atau BBM karena urgent kan. Seperti itu. Ok, Berarti iCare punya 1 telepon sendiri ya pak. Punya mobile phone sendiri untuk berkomunikasi, SMS dan BBM ya pak ya? iya. Kemudian bagaimana sih caranya iCare ini mengelola permintaan yang masuk, sejak dari permintaan ini diterima sampai diinformasikan lagi pada pengguna. Biasanya sih kalau ada, permintaan dari user kita biasanya identifikasi dulu ya permintaannya tuh seperti apa. Lalu kalau misalnya bisa diselesaikan oleh kita pasti kita langsung proses permintaanya itu, lalu kita kabari lagi ke user-nya bila itu sudah solve. Tapi kalau misalnya belum bisa kita selesaikan di kita, misalnya belum kita selesaikan, biasanya kita langsung kabari ke second level, itu biasanya ada PIC-nya, nanti kita minta bantuan dia apakah bisa diselesaikan masalah permintaan ini. Kalau misalnya bisa, nanti di-solve-kan oleh dia, oleh second level, agar ,eh apa namanya, permintaan selesai. Nanti dikabari lagi ke kita oleh second level biasanya. Atau gak kita yang tanya ke second level tersebut apakah sudah selesai masalahnya. Kalau memang sudah selesai baru kita kembali kabari ke user-nya. Berarti yang mengabari terakhir iCare ya pak ya? Iya Lalu bagaimana cara iCare mengelola permintaan yang masuk? Tapi yang terkait dengan opersional bisnis atau saya sebutnya sebagai insiden pak ? Insiden, biasanya kalau insiden yang terkaitnya berat itu biasanya first level gak langsung nangani, biasanya langsung kita oper ke second level dan masalah opersional biasanya ada PIC nya sendiri dengan mas GAL. Oo, dengan GAL. Berarti di first level tidak menangani yang insiden ya pak. Semuanya di GAL. Iya. Nanti setelah Pak GAL selesai, Pak GAL menghubungi langsung atau bagaimana? Universitas Indonesia


129 (Lanjutan)

Id Ide Transkrip wawancara R-15 Iya, Pak GAL langsung ngabari ke user-nya bila insidennya sudah selesai. I-16 6 Ok, kemudian bagaima iCare mengelola masalah dari suatu insiden? termasuk didalamnya mungkin proses pemecahan masalahnya ? R-16 6 Pemecahan masalahnya, biasanya sih kalau udah terlalu rumit permasalahnya biasanya kita langsung diselesaikankan oleh kita pak, Eh kalau biasanya sudah terlalu rumit diselesaikannya oleh second level, Nanti kita tanya seperti yang tadi kita tanya dulu ke second level-nya apakah bisa diselesaikan oleh second level. Insiden-insiden yang tidak terkait eh, insiden yang tidak terkaitnya itu apakah bisa diselesaikan oleh second level. Kalau misalnya dia bisa menyelesaikannya berarti langsung selesai di second level, kabari kita nanti kita kabarin ke user-nya. Tapi kalau second level juga masih kegantung di second level biasanya sih di eskalasi ke vendor-nya, ditanya dulu, mungkin ini prosesnya akan lebih panjang. Nanti vendor yang akan ngabari ke second level, second level nanti ngabari ke kita, baru kita kabari ke user. I-17 Ok gitu, berarti kurang lebih prosesnya seperti yang tadi dijelaskan di awal ya pak ya? R-17 Iya I-18 7 Oke, untuk permintaan-permintaan yang bukan termasuk masalah, bukan termasuk insiden, bisa jadi permintaan e “saya ingin ada report ini pak disini” itu itu seperti apa pak? sama juga dengan yang pertama tadi? Atau berbeda? R-18 7 Biasanya sih kalau insidennya ini tidak terkait, kita identifikasi dulu ya bisa diselesaikan oleh kita apa gak? Kalau misalnya sama sih seperti yang ini, kalau tidak bisa kita teruskan ke second level. I-19 7 Berarti kalau sifatnya sebuah permintaan, misalnya permintaan untuk dibuatkan sebuah reporting, maka dicek dulu kita bisa ngerjain apa tidak. kalau iya, maka diselesaikan kalau tidak maka dieskalasi? R-19 7 Iya kalau tidak maka diekskalasi ke second level. I-20 8 Ok, kemudian kalau misal di sistem kan suka ada perubahan akses pak, bagaimana cara mengelola permintaan perubahan akses ini di iCare? R-20 8 Biasanya user sih sudah tahu kalau ada perubahan seperti itu, biasanya user langsung ya, dia buka edora langsung dia create URF untuk prosesnya. I-21 9 O, Edora. Edora ini aplikasi apa pak? R-21 9 Edora adalah aplikasi dari IT. Nah didalamnya itu, Edora itu bukan hanya create URF, itu kan hanya perubahan akses, Tapi di edora ada juga kayak seperti namanya CDR. CDR itu bisa seperti apa ya, perubahan juga tapi bukan untuk yang request langsung dari user. biasanya sih ada pergantian nama sales. I-22 9 Perubahan data ya pak? R-22 9 Iya perubahan data. Bisa dibilang begitu. I-23 3 Berarti dipertama tadi inputnya melalui email atau telepon dan mobile, Universitas Indonesia


130 (Lanjutan)

Id

Ide

R-23 I-24

5

R-24 I-25

5 5

R-25 I-26

5 6

R-26

6

I-27

6

R-27 I-28 R-28 I-29 R-29

6 6 6 6 6

I-30

5

R-30 I-31

5 10

R-31 I-32 R-32 I-33

10

6

Transkrip wawancara berarti sebetulnya ada 1 lagi ya pak yaitu dengan aplikasi Edora dimana isinya ada URF dan CDR? Iya Oke Pak DRO. Saya ingin konfirmasi lagi pak, Berarti untuk saat ini apakah ada pengkategorisasian suatu insiden? Maksudnya misalnya insiden ini dibagi-bagi nih, ini masalah di hardware, oo engga, atau di software, atau ini masalah di aplikasi, atau masalah di modul aplikasi, atau di page apa gitu? Belum ada? Sampai saat ini sih kayak nya belum ada. O belum ada ya. Kemudian ada panduan formal gak Pak? untuk mengenai insiden yang sifatnya critical? dan prioritasnya bagaimana gitu? Sudah ada panduan formalnya? Belum ada Juga. Belum ada juga ya. Oiya pak. tadi kan ada pemecahan masalah ya Pak ya. Sebetulnya pemecahan masalah itu ada yang jangka pendek dan jangka panjang gitu. Kalau di iCare dia memberikan solusinya itu gimana pak? Apakah ada solusi jangka pendek atau work around? dan solusi jangka panjang atau gimana? Biasanya permasalah yang untuk terkait bisa diselesaikan di iCare itu biasanya diberinya waktu jangka pendek. Kalau misalnya memang problem-nya ini berat dan kemungkinan tidak bisa diselesaikan hari ini pasti kita langsung mengabari ke user-nya lagi, kalau ini jangka waktu yang lebih panjang. Selama dia dikabari bahwa ini membutuhkan waktu jangka panjang, ada solusi jangka pendek juga gak pak? Untuk solusi jangka pendek biasanya ada. Ada, kalau ada diberikan ya pak ya? Iya, diberikan kita kasih tau juga . Kalau tidak ada? Diinformasikan kalau ini pasti membutuhkan jangka waktu yang panjang jadi ditunggu saja oleh user. Biasanya seperti itu. Ok pak. Kemudian tadi tentang insiden dimana beberapa insiden tuh mungkin merujuk ke satu masalah yang sama kan ya pak ya? Bisa jadi kan begitu, kan? Nah, ada tidak pemilahan-pemilahan masalah itu dan kategorisasinya? Atau memang seperti insiden tadi belum ada? Belum ada, masih sama. Ok, di iCare ini punya suatu database atau bank data parameter bisnis yang dapat diubah-ubah IT tidak Pak? Misalnya Rule, atau deployment atau apa gitu? Jadi kita bisa tahu, oo ini rule nya kemarin berubah nih, oo ini database-nya ada deployment yang baru ini Untuk database belum ada. Belum ada ya pak, semua masih by manual ya, dipikiran masing-masing. Iya masih manual Satu lagi Pak, ada bank data lagi gak pak? yang terkait pencatatan error Universitas Indonesia


131 (Lanjutan)

Id

Ide

R-33

6

I-34 R-34 I-35 R-35 I-36 R-36

Transkrip wawancara dan solusinya? Jadi iCare bisa tahu, “oh ini pernah ada masalah seperti ini dan solusi seperti ini” gitu. Ada tidak bank data itu? Sampai saat ini belum ada, biasanya kita langsung ingatannya kita bagaimana cara menyelesaikan masalah itu sih. belum ada dibuat data bank seperti itu Oke Berarti masih dikepala personil iCare masing-masing ya Pak? Iya Oke, terima kasih banyak waktunya Pak DRO Iya, sama-sama Pak. Selamat siang Pak. Selamat Siang.

Daftar Ide: Nomor ide 1 2 3 4 5 6 7 8 9 10

Ide / gagasan Layanan iCare Role iCare information channel Event management process Incident management process Problem management process Request Fulfilment Access Management iCare tools CMDB



132

Lampiran 3 Transkrip Wawancara Dengan IT Analyst / 2nd Level Support Narasumber

: JSE

Jabatan Narasumber : IT Developer / Analyst PT Toyota Astra Financial Service Tanggal Wawancara : 19 November 2014 Tempat Wawancara : Head Office PT Toyota Astra Financial Service

Id I-37

Ide

R-37 I-38 R-38 I-39

2 2 2

R-39 I-40

6

R-40

6

I-41

6

R-41 I-42 R-42 I-43

6

R-43 I-44

10

10

Transkrip Wawancara Selamat Sore Ibu JSE, Saya Bayu dari MTI UI, mau bertanya sedikit tentang proses pengelolaan masalah di iCare. Bisa minta waktunya sebentar? Sore, Silakan Ok, Ibu JSE di Toyota Astra finances, Ibu JSE Sebagai apa? IT developer / analis. Analis. Ok. Analis ini berarti membantu penyelesaikan second level ya Bu JSE ya? Iya, betul. Oke, mau nanya Bu JSE, bagaimana pengelolaan masalah dari suatu insiden yang termasuk didalamnya proses pemecahan masalahnya gitu? Kalau insiden itu yang diterima biasanya ada 3 jalur penyelesaiannya. Yang pertama ada yang dapat langsung diselesaikan oleh second level, ada juga yang perlu di discuss dengan second level lainnya di HO atau ada yang langsung disampaikan langsung ke vendor untuk penyelesaiannya. Biasanya second level akan mencoba solve sendiri terutama jika insiden tersebut udah pernah dihadapi tapi jika dikira memang tidak mungkin diselesaikan sendiri maka akan disampaikan ke second level yang terkait atau PIC yang berhubungan. Kalau memang masalahnya tersebut membutuhkan bantuan vendor maka akan dikirimkan ke PIC yang bersangkutan untuk di follow up ke vendor. Ok, berarti untuk prosesnya seperti itu ya bu JSE ya. Mau saya konfirmasi bu. Sudah ada belum sih panduan formal untuk pemilah-milahan masalah terkait dengan tingkat kesulitan penyelesiaannya? Untuk saat ini sih belum ada ya. O, belum ada ya? Iya. Kemudian ada tidak semacam bank data atau database untuk parameter bisnis untuk yang diubah-ubah oleh IT. Misalnya ada deployment atau ada rule ada konfigurasi? Untuk yang mencatat semuanya sih belum ada Belum ada ya? Universitas Indonesia


133 (Lanjutan)

Id Ide Transkrip Wawancara R-44 Iya belum ada. I-45 10 Kalau semuanya belum ada, sebagian sudah ada atau belum? R-45 10 Kalau rule sebenarnya kalau rule pergantian rule ada. I-46 10 O, ada log nya? R-46 10 Ada log-nya cuman kalau untuk deployment, perubahan konfigurasi gak ada. I-47 10 Log-nya itu termasuk perubahan rule nya ini terkait apa gitu? atau hanya filenya saja? R-47 10 O, hanya backup-nya saja I-48 6 O hanya backup-nya saja. Adakah bank data atau database yang mencatat error yang pernah terjadi? Sehingga iCare bisa langsung tahu bahwa error ini dulu cara mengatasinya seperti apa? R-48

6

I-49

6

R-49 I-50

6 6

R-50

6

I-51 R-51 I-52

6 6 7

R-52

7

I-53 R-53

7 7

I-54

9

R-54 I-55

9 9

Kalau bank data-nya sebenarnya ada tapi untuk pencarian masalahnya itu masih tergantung sama masing-masing analis-nya. Jadi butuh inget-inget sebelumnya pernah melakukan itu apa engga. Jadi bisa dicari lagi karena nyari nya masih susah. Jadi di ingat-ingat dulu, jika sudah pernah merasa sudah pernah mengatasi hal itu baru dicari ya. Iya Tapi itu detail ya bu ya? jadi ada masalahnya apa, cara penyelesaiannya apa? Ada semua disitu ? Belum, belum ada struktur yang harusnya seperti apa sih, cuman tergantung orang yang pencatatan masing-masing berarti free text iya free text Ok, pertanyaaan selanjutnya bagaimana mengelola permintaan yang tidak terkait masalah atau insiden. Misalnya untuk permintaan untuk reporting atau ada perubahan tampilan dan sebagainya? Semuanya masih diterima melalui prosedur rutin di iCare melalui dari penerimaan telepon, email kemudian diidentifikasi masalahnya, kalau misalnya memang dicek bukan insiden maka user akan diminta untuk membuat URFA kalau misalnya ada request-request namun prioritasnya beda lebih, rendah daripada insiden. O dari URFA tadi lanjutannya gimana ibu, setelah user isi URFA lalu? User perlu approval ke atasannya setelah itu nanti masuk ke IT dept head, lalu jalurnya nanti di tentukan, disampaikan ke PIC masingmasing. PIC yang akan melakukan perubahan itu ya. URFA ini berarti ada suatu aplikasinya tersendiri ya Bu? Ada-ada, terpisah sendiri Itu sama dengan yang di Edora itu tidak sih bu? yang dipakai first level sama ya? Universitas Indonesia


134 (Lanjutan)

Id Ide Transkrip Wawancara R-55 9 Sama. I-56 1 Berarti didalamnya ada urfa, URF, CDR? R-56 1 Iya ada URFA, URF, CDR. I-57 Tapi prioritasnya lebih rendah berarti ya Bu untuk yang perubahan ini ya? R-57 Iya betul. I-58 8 Ok, yang terakhir bu, pertanyaannya, bagaimana pengelolaan permintaan dari perubahan akses? R-58 8 Biasanya sih kalau akses masih di-handle sama first level. kecuali kalau misalahnya ada yang approval gitu butuh bantuan dari second level tapi itu ada PIC-nya masing-masing. Dari first level akan langsung menyampaikan langsung ke PIC nya. I-59

6

R-59

1

I-60 R-60 I-61 R-61 I-62

1 1

Ok, Oiya bu saya mau mengkorfirmasi kembali pertanyaan yang pertama. berarti insiden itu ada tiga jalur penyelesaian ya? Nah itu kan jalur penyelesaiannya, jalur masuknya dari mana Bu? Jalur masuknya sama. biasanya dari email atau telepon, yang bisa langsung diterima langsung oleh second level. Tapi itu email sih biasanya yang diterima oleh second level, tapi kalau biasanya kalau telepon diterima oleh first level. Berarti email bisa saja dari user langsung ke second level? Iya bisa email langsung Ok, Bu terima kasih banyak atas waktunya Bu JSE Sama-sama. Terima Kasih.

Daftar Ide: Nomor ide 1 2 3 4 5 6 7 8 9 10

Ide / gagasan Layanan iCare Role iCare information channel Event management process Incident management process Problem management process Request Fulfilment Access Management iCare tools CMDB



135

Lampiran 4 Transkrip Wawancara Dengan Supervisor IT Helpdesk Narasumber

: GAL

Jabatan Narasumber : IT Developer / Analyst PT Toyota Astra Financial Service Tanggal Wawancara : 19 November 2014 Tempat Wawancara : Head Office PT Toyota Astra Financial Service

Id I-63

Ide

R-63 I-64 R-64

2 2

I-65

1

R-65

1

Transkrip Wawancara Selamat, Pak GAL. Saya Bayu dari MTI UI meminta waktunya sebentar terkait mengenai proses-proses di IT helpdesk atau biasa yang disebut iCare. Bisa minta waktunya sebentar Pak? Selamat sore mas bayu, gak pa pa mas bayu silakan. Maaf sebelumnya Pak GAL, di iCare posisinya sebagai apa Pak? Saya sebagai supervisor disana, jadi sebagai pengawas operasional seharihari dari setiap beraktivitas dan task-task yang masuk ditempat kami. Itu memang PIC-nya di Saya. Saya bertanggung jawab terhadap penyelesaiannya, monitoringnya, seperti itu. Oke Pak, Pertanyaan pertama ya Pak ya. Permintaan yang masuk ke iCare itu apa aja? Kalau kita bicara mengenai permintaan mungkin saya jawabnya mulai dari pelayanan kali ya secara service, yang masuk ketempat kita itu secara sederhana kita bagi menjadi tiga itu yang pertama problem, request dan yang ketiga itu adalah informasi. Problem, problem disini adalah problem yang dilihat dari sisi yang levelnya user ya jadi tidak secara internal lagi. Disini problem yang saya maksud adalah kendala permasalahan yang ditemukan oleh user mengenai sistem informasi dan juga fasilitas perangkat kerja IT yang digunakan. Seperti misalnya error ketika menjalankan suatu proses-proses tertentu ataupun juga ada proses-proses yang abnormal, isu tentang jaringan, dan juga seperti printer rusak ataupun ketidaksesuain data, hal-hal seperti itu yang kita kategorisasikan sebagai problem. Nah kemudian yang kedua adalah request, request itu permintaan pelayanan dari user yang masuk ke iCare untuk menunjang kegiatan pekerjaan mereka ketika mereka berinteraksi dengan sistem informasi dan perangkat kerja yang digunakan seperti misalnya apa request? Misalkan adalah unlock password computer, kemudian ada permintaan cetak ulang polis, mencetak ulang dokumen kontrak, kemudian perubahan data atau kita sebut change data request. Mungkin contoh lainnya user request form, kalau user request form ini dia lebih kearah permintaan untuk mengcreate misalkan user login , modify user login, kemudian dia juga meminta device hardware yang baru. Seperti itu. Nah setelah problem dan request yang ketiga kita kategorisasikan sebagai informasi. Informasi itu interaksi antara user dengan team support kita Universitas Indonesia


136 (Lanjutan)

Id

Ide

I-66

R-66

3

I-67 R-67

3 3

I-68 R-68 I-69

4

R-69

4

Transkrip Wawancara terkait adanya kebutuhan pengetahuan seputar informasi yang digunakan, atau juga mereka butuh data apa saja yang tersimpan didalamnya, misalkan flow proses pada aplikasi seperti apa, kemudian mereka mau mengetahui apa last update dan modifier-nya ini siapa dan kapan, kemudian juga data-data nomor polis asuransi, status aplikasi dan juga lain-lain. Secara garis besar seperti itu. Oke Pak GAL, tadi disebutkan ada change data request dan juga ada user request form. Kalau tidak salah ini dari aplikasi yang terpisah ya Pak ya? Ada dari aplikasi Edora kalau tidak salah. Ya betul, aplikasinya ini terpisah. Dia berdiri sendiri. Jadi permintaan ini secara formal kita sistem sistemasikan di aplikasi tersebut. Permintaan yang masuk ke iCare itu melalui apa saja ya Pak ya? Ya jadi setiap permintaan atau pelayanan yang masuk ke iCare itu ada 3 jalur sebenarnya yang kami sediakan. Pertama jalur email. Jadi silakan anda bisa kirimkan email ke [email protected]. Itu alamat email kami. Jadi team kami akan segera memproses permintaan pelayanan anda dan tentunya di jam operasional kerja. Yang kedua adalah jalur telepon, jalur telepon bisa menghubungi kami melalui VOIP 8998, kalau lagi berada di kantor cabang TAfinance. Tapi apabila anda berada di luar cabang, misalkan lagi di dealer ataupun di luar kota, itupun bisa menghubungi kami di nomor (021) 57898998. Atau kalau lebih mudah juga bisa sms atau call ke handphone kami, kami ada handphone, di 081282223640 pada jam operasional kerja. Sebagai informasi saja jam operasional kerja kami dimulai pukul 7 pagi sampai jam 6 sore berlaku pada hari senin-jumat dan pada hari sabtu, khusus hari sabtu kami mulai melayani dari jam 8 pagi sampai jam 2 siang. Berarti ada handphone yang memang khusus dipergunakan untuk komunikasi di iCare ya pak ya? Betul, jadi kami memang menyediakan 1 dedicated handphone yang kami taruh di ruangan helpdesk support. Lalu, bagaimana iCare mengelola permintaan yang masuk sejak permintaan itu diterima hingga informasinya kembali kepada user? Oke, Bagaimana permintaan itu diproses. Bagaimana pelayanan itu diproses oleh kami urutannya sederhana saja, Saya jelaskan secara garis besarnya. Jadi pertama team kami heldesk support, dia menerima pelayanan dari user itu melalui 3 jalur yang tadi, bisa melalui email, telepon atau pun melalui mobilephone. Dan kedua setelah menerima, kita identifikasi yang pelayanan yang diterima, kita identifikasi setelah identifikasi selesai kita proses, setelah proses kita selesaikan. Apabila sesuai dengan wewenangnya, sesuai dengan keahliannya maka bisa langsung diselesaikan oleh helpdesk support. Tapi kalau gak bisa, ini dibutuh suatu technical solution yang lebih advance lagi itu maka akan diteruskan lagi ke second level, second level ini ada di head office. Nah kemudian setiap pelayanan yang sudah dikerjakan team helpdesk support akan menginformasikan, apa namanya, e hasilnya, result-nya seperti apa. Universitas Indonesia


137 (Lanjutan)

Id

Ide

I-70 R-70

4 4

I-71 R-71 I-72

4 4

R-72 I-73

5

R-73

5

I-74 R-74 I-75

5

R-75

5

I-76 R-76

5

Transkrip Wawancara Biasanya kita pake email, kita email ke user bahwa sudah selesai dan yang terakhir setelah kita informasikan kita catat setiap pelayanan yang sudah deliver ke user. Seperti itu. Pencatatannya melalui apa Pak? Pencatatanya sederhana, kita punya aplikasi sederhana dimana aplikasi web based. Jadi kita input cabangnya dari mana, kemudian deskripsi pelayanannya yang kita berikan seperti apa, kemudian eksekutornya atau PIC penyelesaiannya siapa, kemudian kita tinggal submit saja. Aplikasi ini kalau tidak salah Issue log ya pak ya? Betul nama aplikasinya issue log. Kemudian tadi ada disebutkan ada identifikasi pelayanan yang diterima, disini identifikasi itu terkait dengan batasan, wewenang dan keahlian ya? Betul. Oke, bagaimana iCare mengelola permintaan yang masuk yang terkait dengan operasional bisnis atau biasa yang disebur dengan insiden? Kalau pengelolaan seperti itu, gambaranya sama saja seperti yang tadi saya jelaskan pengelolaan permintaan dan yang lainnya. Jadi tetap diindentifikasi, setelah identifikasi, apakah sanggup diselesaikan di first level, kalau tidak bisa maka problem ini akan naik ke saya dulu, tentunya ke saya dulu, untuk kemudian saya analisa, jadi apabila memang bisa diselesaikan, akan langsung saya selesaikan, apabila tidak bisa saya komunikasikan dengan orang-orang di head office bersama dengan tim IT yang lain bagaimana penyelesaiannya, dan selanjutnya apabila memang extreme-nya tidak bisa juga diselesaikan oleh tim internal IT maka kita harus membawa masalah ini, problem ini, ke vendor untuk diselesaikan. Nah setelah penyelesaian di lakukan, ya saya akan update kembali kepada user, kepada yang melapor, bahwa sudah selesai. Dan kemudian masalah ini akan dicatat issue log dengan PIC penyelesaianya itu di level second level, di saya dan teman-teman di head office Saat masalahnya sudah selesai, nanti prosesnya bagaimana Pak? Sudah dikerjakan oleh second level misalnya? Maksudnya? Jika permasalahan diekskalasi ke second level lalu dicatat? Artinya kan belum closing. Setelah second level sudah melakukan penyelesaiannya, nanti bagaimana? Maksudnya second level menghubungi langsung atau second level ke iCare dulu baru nanti iCare ke user? Saat ini dari second level akan langsung me-reply email, kalau user ada email, kalau user gak ada email biasanya second level akan langsung meng-email pake akun email-nya [email protected], jadi bukan pake akun email pribadi. Jadi tetap second level yang akan meng-email ke user langsung meng-cc-kan helpdesk support itu sendiri sehingga merekapun juga tahu bahwa ini sudah selesai. Semua second level punya email iCare? Tidak semua second level, hanya beberapa orang yang memiliki yang, apa, di email-nya itu akun email [email protected] Universitas Indonesia


138

Id I-77

R-77 I-78 R-78

I-79 R-79 I-88

R-88

I-89 R-89

I-90 R-90

Ide Transkrip Wawancara 7 Lalu bagaimana mengelola permintaan yang tidak terkait dengan insiden? Jadi misalnya permintaan untuk membuat reporting, permintaan data dan sebagainya? 7 Permintaan yang tidak terkait insiden seperti yang mas bayu bilang reporting, permintaan, apa tadi yang pertama? 7 Permintaan data, reporting. 7 Permintaan data, reporting, jadi eh dalam menerima setiap layanan juga tim kami melihat apakah ini wewenangnya memang di kita atau bukan seperti itu. Ada beberapa hal yang tidak dalam wewenang kita, yang memang tidak bisa langsung mengeluarkan data, wewenangnya, dalam hal ini yang kami lakukan adalah menyampaikan prosedur kepada pengguna, kepada user, bahwa jika ingin meminta sesuatu yang di luar wewenang, kita itu silakan konsultasikan kepada atasan terkaitnya dulu tentunya, kemudian ada jalur resmi yang bisa dipakai yaitu menggunakan URFA (user request form application) dan yang dari aplikasi tersebut nanti akan diteruskan kepada IT head office. Seperti itu. Jadi URFA. Kita lebih banyak menangani operasional, tapi apabila untuk permintaan-permintaan baru, apalagi yang terkait dengan insiden ya kami hanya menyampaikan prosedur tersebut. 7 URFA itu yang melalui edora ya Pak ya? 7 Betul, aplikasinya masih di edora 6 Oke, kembali lagi terkait dengan insiden dan masalah. Untuk pengelolaan masalah dari suatu insiden prosesnya gimana ya pak? Ya jadi apakah ada solusi jangka pendek dan solusi jangka panjang? Atau bagaimana? 6 Solusi jangka pendek ada kami berikan melihat urgensitas dari lapangan. Karena ada beberapa hal yang kita gak bisa nunggu. Jadi kita coba pikirkan alternatif tercepatnya bagaimana. Entah itu tembak data secara langsung, tapi ini tidak disarankan. Ataupun juga ini yang disarankan adalah jalankan manual proses dulu apakah bisa seperti itu. Tentunya manual proses ini dijalankan dengan kami informasikan dengan atasan dari user terkait yang melaporkan. Jadi ekskalasinya jelas jadi tahu bahwa ini tidak bisa di-deliver segera penyebabnya, jadi silahkan jalankan proses manual terlebih dahulu. Kalau solusi jangka panjang setiap permasalahan itu biasanya kami laporkan, koordinasi kerjasama dengan IT di head office untuk diperbaiki segera. Dan biasanya dalam beberapa waktu itu ada solusi yang dinaikan ke dalam production terhadap masalah-masalah yang pernah dilaporkan selama operasional berjalan. 6 Pengelolaannya berarti masih by email ya pak ya? Belum ada sitem? 6 Untuk pengelolannya betul by email, untuk informasi penanganan jangka pendeknya pun juga helpdesk support juga tidak memiliki wewenang untuk menyampaikan. Biasanya juga itu informasi dari saya untuk keputusannya itu seperti apa. 6 6

Tapi dimasukkan ke dalam issue log sebagai pencatatan? Betul, dimasukkan ke dalam issues log



139 (Lanjutan)

Id I-91 R-91

I-92 R-92 I-93

Ide Transkrip Wawancara 8 Oke, lalu bagaimana iCare mengelola permintaan terkait dengan perubahaan akses? Untuk perubahan rotasi? Atau bagaimana begitu. 8 Ya, perubahan rotasi itu, atau perubahan / modify user itu dilakukan prosedurnya sederhana, silahkan gunakan URF, anda tulis disana kategorinya apa? termin perubahaannya apa, dan submit. Nanti setelah atasan anda menyetujui, IT akan segera menyelesaikan. 8 8

R-93 I-94

R-94 I-95 R-95 I-96 R-96 I-97 R-97 I-98 R-98

Melalui Edora lagi ya Pak ya? Betul, edora lagi. Oh baik saat ini insiden yang masuk sudah ada prioritasi, pemberiaan prioritas yang formal? Misal untuk insiden ini maka prioritasnya low untuk masalah yang lain prioritasnya harus high? Saat ini kami belum memiliki prioritas seperti itu. Oke, jadi untuk pemecahan masalah pun belum ada kategorisasinya ya pak. Misalnya untuk masalah ini maka perlu sekian analis, untuk yang ini maka vendor. Belum, belum. Belum ada panduaanya? Belum ada prosedur sampai ke tahap itu. Oke, untuk panduan, tadi kan ada terkait wewenang juga ya pak ya? Ya, Betul Untuk panduaan wewenangnya berarti keputusannya ada di supervisor? Atau ada panduan secara yang terdokumentasi? Tidak untuk secara prosedur, dokumentasi kami masih belum banyak dan rasanya kalau buat wewenang seperti itu masih ada ditempat saya. Baik pak GAL terima kasih banyak atas waktunya selamat sore. Selamat sore, terima kasih, sama-sama mas bayu .

Daftar Ide: Nomor ide 1 2 3 4 5 6 7 8 9

Ide / gagasan layanan iCare Role iCare information channel event management process incident management process problem management process Request Fulfilment Access Management iCare tools



140

Lampiran 5 Transkrip Wawancara dengan IT Development Head Narasumber

: TSU

Jabatan Narasumber : IT Development Department Head PT Toyota Astra Financial Service Tanggal Wawancara : 26 November 2014 Tempat Wawancara : Head Office PT Toyota Astra Financial Service

Id I-99

Ide

R-99 I-100 R-100

2 2

I-101 R-101

2 2

I-102

11

R-102

11

I-103

12

Transkrip Wawancara Halo, Selamat Pagi Pak TSU, Saya Bayu dari MTI UI mau minta waktunya sebentar bisa? Pagi Bayu, Bisa, silakan. Pak TSU, di Toyota Astra Finances sebagai IT Development Head ya? Ya, Saya TSU bekerja di Toyota Astra Finance dan bertanggung jawab di IT Development Department dan kemudian saya sudah bekerja kurang lebih 8 tahun Oke Pak terkait dengan iCare disini pak TSU fungsinya seperti apa? iCare. Karena fungsi dari iCare adalah memberikan IT support untuk kebutuhan operasional bisnis baik terkait aplikasi, IT troubleshooting maupun network infrastructure dan saya bertanggung jawab bagian aplikasi sehingga untuk operasional iCare sendiri masih melekat di IT aplikasi. Oke, terima kasih Pak. Nah, saya ada beberapa pertanyaan, yang pertama apakah fungsi dan aktivitas dari iCare? Fungsi dari iCare adalah kita harus segera memberikan IT support bagi operasional bisnis yang membutuhkan bantuan, baik bantuan itu dari sisi aplikasinya maupun troubleshooting IT devices maupun network infrastructure-nya. Dan biasanya bantuan yang diberikan, service yang kita berikan berikan ke operation berupa problem, problem solving, request, request untuk dari operation maupun sampai ke pertanyaan yang terkait dengan informasi. Oke Pak. Apakah ada dukungan dari manajemen Pak untuk operasi layanan iCare ini? Kalau ada seperti apa saja Pak?



141 (Lanjutan)

Id R-103

I-104

R-104

I-105 R-105

I-106

Ide Transkrip Wawancara 12 Manajemen committed untuk membantu iCare karena dari manajemen melihat kepentingan untuk menjaga existing operasional bisnis sama pentingnya dengan membangun inisiatif bisnis yang baru. Karena inisiatif bisnis baru untuk membuka peluang baru. Namun existing bisnis yang telah menghasilkan revenue bagi perusahaan harus tetap dijaga kesinambungannya dan performance-nya. Oleh karena itu manajemen memperhatikan pelaporan dari hasil kerja iCare baik manajemen dari local maupun manajemen principal kami dari Toyota. Dan beberapa inisiatif yang diperbolehkan oleh manajemen untuk membangun iCare yaitu akan diperkuat baik dari sisi proses, baik dari sisi people, maupun dari sisi tools-nya. Baik sisi proses kita ingin mempermudah bagaimana cabang bisa berhubungan dengan iCare, bagaimana team iCare sendiri bisa mencatat request atau pertanyaan dari cabang, terus kemudian kalau dari sisi tools kita juga akan memperkuat pencatatan selama ini masih tersebar dibeberapa sistem atau bahkan manual file. Kita ingin itu menjadikan satu aplikasi yang terintegrasi. Begitu juga dengan peoplenya, kapasitas dari people-nya terus kita tingkatkan baik melalui training, trainingnya baik yang sifatnya technical maupun yang soft skill. 12 Pernah ada ini tidak Pak? Terkait dengan dukungan manajemen tadi, pernah ada misalnya training, training yang sifatnya ke personil-personil iCare itu? 12 Jadi, sekitar 1 tahun yang lalu, bekerjasama ehh apa, sekitar 1 tahun yang lalu team iCare kita memberikan training soft skill terkait dengan pelayanan service yang diberikan. Jadi bagaimana, bagaimana team iCare menyapa, bagaimana team iCare memberikan respon dan tanggapan, bagaimana berbicara melalui telepon, bagaimana menulis dalam email seperti itu. 13 Oke, bagaimana budaya perusahaan di Toyota Astra Finances dan implikasinya kepada operasi layanan iCare? 13 Sebelumnya dapat dijelaskan bahwa Toyota Astra Finances memiliki core values yang diyakini sebagai budaya perusahaan yaitu excellent, professional, good relation dan costumer focus. Dan untuk menjalankan nilai dari perusahaan tersebut kami memiliki service behavior yang terdiri dari simple, care dan fast. Team iCare sebagai bagian dari Toyota Astra Finance pun dan melayani user-user yang merupakan, e melayani dari user-user Toyota Astra Finances kami menganut nilai dan behavior yang sama. Jadi kami memiliki standardized greeting pada saat menerima telepon, terus kemudian secara profesional pun kami akan mencatat segala request ataupun log yang ada, begitu kami akan monitor respon time yang dari iCare untuk menjaga apakah delivery service dari iCare masih acceptable atau tidak. Walaupun masih ada beberapa hal yang harus di-improve supaya budaya dan behavior dari perusahaan lebih tercermin lagi dan termonitor lagi dari deliverable iCare. 14 Oke Pak. Apakah ada kebijakan-kebijakan perusahaan yang mempengaruhi operasi layanan iCare?



142 (Lanjutan)

Id R-106

I-107

R-107

I-108 R-108

Ide Transkrip Wawancara 14 Kebijakan yang secara khusus mengatur operasional dari iCare belum ada. Namun ada beberapa guidance yang kami gunakan jadi seperti petunjuk pelaksanaan gitu yaitu mengatur jam operasional iCare , bagaimana jalur pelaporan? Escalation/ekskalasi itu ke titik mana, sampai kami berinisitif memberikan report SLA untuk team operation sebagai bentuk pertanggung jawaban SLA ke operation. 14 Report SLA ini bentuknya apakah misalnya ada kasus ini atau incident A maka penyelesaian sekian? Atau lebih kearah email atau misalnya atau availibilitas server? 14 Kebetulan saat ini sayangkannya belum ada kemampuan atau pencatatan untuk bisa melihat berapa lama suatu problem itu masuk, dari mulai masuk tercatat sampai itu, itu diberikan respon, sampai itu diselesaikan, sehingga SLA report yang kami memberikan itu hanya berupa availability dari service yang diberikan oleh iCare, berapa lama waktu server A, berapa target network yang kita capai, network availability yang kita capai, sampai dengan berapa jumlah secara quantity, berapa jumlah ticket yang masuk, telepon yang masuk, telepon tidak terjawab dan seturusnya . Oke mungkin saat ini itu dulu Pak TSU terima kasih banyak atas waktunya Terima Kasih bayu.

Nomor ide 2 11 12 13 14

ide/gagasan Role Fungsi iCare Dukungan manajemen kepada iCare Pengaruh Budaya perusahaan kepada iCare Pengaruh Kebijakan perusahaan kepada iCare



143

Lampiran 6 Transkrip Wawancara dengan IT Analyst BAF Narasumber

: AP

Jabatan Narasumber : IT Analyst PT Bussan Auto Finance Tanggal Wawancara : 24 December 2014 Tempat Wawancara : Melalui surel

ID I-109

Ide

R-109

13

Transkrip Wawancara Perkenalkan Saya bayu dari MTI UI. Saya ingin menanyakan beberapa kepada Bapak terkait dengan IT Helpdesk di BAF. Bagaimana role dan manpower dari IT Helpdesk? Peran IT Helpdesk: Sebagai pintu utama dalam menerima permintaan keluhan dari pengguna. Menyaring keluhan dan menginformasikannya kepada pihak yang lebih tahu. Mencatat keluhan pelanggan. Memprioritaskan keluhan yang perlu direspon cepat Man power: 12 orang

I-110 R-110 I-111 R-111

I-112 R-112

I-113

14

15

16

IT Helpdesk apakah dalam 1 lokasi atau tersebar? Berapa cabang yang dilayani? IT Helpdesk dikumpulkan dalam 1 ruangan yang melayani 188 cabang di seluruh Indonesia Permintaan yang masuk ke IT Helpdesk itu apa saja? • Reset password aplikasi • Bugs/error pada aplikasi • Koneksi jaringan bermasalah • Koreksi Data • Permohonan akses internet atau aplikasi • Penambahan kuota email • Laptop rusak • Permintaan data • dll Permintaan yang masuk ke IT Helpdesk itu melalui apa saja? • Email • Telepon • Formulir Bagaimana IT Helpdesk mengelola permintaan yang masuk dari sejak permintaan diterima hingga informasi kembali kepada pengguna?



144 (Lanjutan)

R-113

17

I-114 R-114

18

I-115 R-115

19

I-116 R-116

I-117 R-117

20

21

• Mencatatnya pada aplikasi manajemen tiket (Mantis) • Jika IT Helpdesk dapat melakukannya, maka mereka akan langsung memberikan arahan atau petunjuk penyelesaian masalah kepada pengguna. Jika bukan wewenang IT Helpdesk, maka mereka akan melakukan eskalasi kepada tim Ahli yang berwenang. IT helpdesk akan memonitor perkembangan isu melalui aplikasi manajemen tiket. Bagaimana IT Helpdesk mengelola permintaan yang masuk yang terkait dengan operasional bisnis atau yang disebut dengan insiden? • Mencatatnya pada aplikasi manajemen tiket (Mantis) • Menginformasikan isu tersebut kepada pihak-pihak terkait dan manajemen melalui email • Memonitor perkembangan melalui aplikasi manajemen tiket Bagaimana mengelola masalah dari suatu insiden, termasuk didalamnya proses pemecahan masalah? • Tim ahli melakukan investigasi atas insiden yang terjadi • Tim ahli menjelaskan kronologis penyebab terjadinya insiden dengan membalas email yang dikirim IT Helpdesk dan mencatatnya pada aplikasi manajemen tiket • Tim ahli memberikan work arround dan solusi permanennya untuk dicatat pada aplikasi manajemen tiket • Menyiapkan tim dan resource untuk solusi tersebut • Eksekusi Bagaimana mengelola permintaan yang tidak terkait masalah atau insiden? • Mencatatnya pada aplikasi manajemen tiket (Mantis) • Melakukan eskalasi kepada Tim Ahli yang berwenang • Melakukan monitor terhadap perkembangan pengerjaan atas permintaan tersebut • Konfirmasi melalui email atau telepon bahwa akses sudah diberikan Bagaimana mengelola permintaan dari perubahan akses? • Mengajukan permintaan melalui formulir yang disediakan IT Helpdesk • Mencatatnya pada aplikasi manajemen tiket (Mantis) • Melakukan eskalasi kepada Tim Ahli yang berwenang • Melakukan monitor terhadap perkembangan pengerjaan atas ppermintaan tersebut • Konfirmasi melalui email atau telepon bahwa akses sudah diberikan

Nomor ide 13 14 15 16 17 18

Ide/gagasan fungsi IT helpdesk BAF skala IT Helpdesk BAF layanan IT Helpdesk BAF Saluran informasi IT Helpdesk BAF pengelolaan permintaan IT Helpdesk BAF pengelolaan insiden IT Helpdesk BAF Universitas Indonesia


145 (Lanjutan)

Nomor ide 19 20 21

Ide/gagasan pemecahan masalah di IT Helpdesk BAF pemenuhan permintaan di IT Helpdesk BAF perubahan akses di IT Helpdesk BAF



146

Lampiran 7 Minutes of Meeting Minutes of Meeting dari Focus Group Discussion perubahan yang diterima dari gap model konseptual dengan dunia nyata. Tempat

: Kantor Pusat Toyota Astra Finance

Waktu

: 24 Desember 2014 pukul 15.00 WIB



147 (Lanjutan)



148 (Lanjutan)



149

Lampiran 8 Profil Organisasi PT. Toyota Astra Financial Services, atau yang biasa disebut Toyota Astra Finance, merupakan perusahaan kerjasama antara Toyota Financial Services Corporation (TFSC) dan PT. Astra International Tbk (AI) yang ditandai dengan penandatangan kerjasama pada Oktober 2006. Toyota Astra Finance merupakan cabang ke-31 dari TFSC diseluruh dunia. Meskipun Toyota Astra Finance perusahaan baru tetapi Kerjasama antara kedua induk perusahaan ini di Indonesia sudah terjalin lebih dari 30 tahun. Toyota Astra Finance memiliki tujuan untuk menjadi pilihan utama dalam menyediakan jasa layanan pembiayaan untuk kepemilikan kendaraan Toyota dengan menjunjung tinggi sikap profesionalisme, berusaha memberikan yang terbaik, memiliki semangat kerjasama yang berfokus kepada pelanggan. Toyota Astra Finance berusaha membantu mewujudkan impian pelanggan untuk memiliki kendaraan Toyota dengan menyediakan pelayanan yang mudah dan terjangkau. Saat ini Toyota Astra Finance memiliki 27 cabang diseluruh pulau Sumatera, Jawa, dan Kalimantan. Layanan yang berikan Toyota Astra Finance adalah: 1. Consumer Vehicle Financing Ditujukan kepada pelanggan yang membeli kendaraan untuk keperluan non-komersial. 2. Business Vehicle Financing Ditujukan sebagai solusi pembiayaan yang didesain untuk mendukung bisnis pelanggan dan cocok untuk kebutuhan atas pembiayaan yang melibatkan unit kendaraan dalam jumlah besar. 3. Vehicle Financial Lease Ditujukan

untuk

Badan

Usaha/Perusahaan

yang

membutuhkan

pembiayaan dalam bentuk penyewaan yang melibatkan jumlah unit kendaraan yang besar. Untuk menjalankan operasionalnya maka Toyota Astra Finance memiliki struktur organisasi sebagai berikut:



150 (Lanjutan)

Dibawah kepimpinan presiden direktur dan wakil presien direktur terdapat 3 direktorat yaitu Marketing & Operation Directorate, Finance & Administration Directorate, dan Human Resource Directorate. Pesiden direktur dan wakil presiden direktur dibantu 3 departemen yaitu Corporate Internal Audit Department, Corporate Legal & Secretary Department, dan Corporate Planning & Invesment Department. Pada Marketing & Operation Directorate terdapat divisi marketing, divisi General Business Development yang dipimpin seorang deputi kepala divisi, kemudian divisi-divisi operasional yang dibedakan berdasarkan area operasional yaitu area 1, area 2, dan area 3. Pada direktorat Human Resource Directorate hanya memiliki 1 divisi yaitu Human Resource Division. Pada Finance & Administration Directorate terdapat 3 departemen yaitu divisi Risk Management, divisi Finance, dan Divisi IT & GA (information technology and General Affairs). Di dalam divisi IT & GA terdapat departemen IT Development, IT Operation, dan General Affairs. IT Operation menangani operasional TI terkait dengan infrasturktur, jariangan, dan sistem server. Sedangkan IT Development menangani pengembangan aplikasi dan pemeliharaan core system. IT Helpdesk menangani permintaan bantuan terkait informasi TI, perubahaan data, sampai gangguan terhadapat core system sehingga IT Helpdesk Universitas Indonesia


151 (Lanjutan)

menempel di dalam departemen IT Development, mesikupun IT Helpdesk juga melayani permintaan gangguan terkait infrastruktur dan jaringan sebagai pintu gerbang masuknya permintaan-permintaan pengguna.

Daftar aplikasi yang dipergunakan pada Toyota Astra Finance yang dipetakan menggunakan Grid McFarlan adalah sebagai berikut: 1.

Support E-Dora (IT Helpdesk Request), Afica (Business Trip Flight Booking Request), TAccess (Corporate Portal). Aplikasi diatas masuk kedalam kategori support karena sifatnya hanya pendukung. Jika aplikasi tidak dapat diakses maka tidak mengganggu proses bisnis utama. CRM (Customer Relationship Management) Application Saat ini aplikasi CRM sudah tersedia di Toyota Astra Finance. Namun penggunaan aplikasi ini masih sangat terbatas sekali sehingga belum mampu memenuhi tujuan utamanya dan putusnya layanan atas aplikasi ini belum mengganggu proses bisnis utama.

2.

Key Operational Confins (Core System), Axapta (backend system untuk HR, Finance, Accounting, dan Treasury) Aplikasi diatas masuk kategori key operational karena apabila tidak dapat diakses maka proses bisnis organisasi terhenti.

3.

High Potentional Mobile Survey, Mobile Collection, Confins (Core System) Aplikasi mobile mempercepat proses penanganan kolekasi dan survei pelanggan, hal ini menjadi competitive advantage bagi organisasi.

Selain

itu

Confins

yang

sangat

mudah

untuk

dikonfigurasi memberikan kemudahan organisasi untuk meluncurkan inisatif bisnis baru seperti forklift, used car, syariah, dan lain-lain. Universitas Indonesia


152 (Lanjutan)

Infrastruktur TI yang sudah dimiliki oleh Toyota Astra Finance adalah sebagai berikut: 1.

Koneksi jaringan ke kantor-kantor cabang menggunakan layanan dari penyedia jasa dengan lebih dari satu koneksi jaringan yang dapat saling balancing dan failover.

2.

Pusat data lama di kantor pusat.

3.

Pusat data operasional di penyedia jasa pusat data.

4.

Server Disaster Recovery Center di penyedia jasa DRC.

5.

Multi channel untuk pembayaran melalui ATM, kantor Pos, TAPA Permata, dan AutoDebit.

Jumlah pengguna TI di Toyota Astra Finance mencapai 700 pengguna yang tersebar di 33 kantor cabang yang didukung oleh 6 orang agen pada IT Helpdesk.



153

Lampiran 9 Contoh SOP Toyota Astra Finance



154 (Lanjutan)



155 (Lanjutan)



156 (Lanjutan)



UNIVERSITAS INDONESIA MANAJEMEN OPERASI LAYANAN IT HELPDESK: STUDI KASUS DI PT TOYOTA ASTRA FINANCIAL SERVICES KARYA AKHIR

Recommend Documents