UNIVERSITAS INDONESIA MANAJEMEN OPERASI LAYANAN...

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


iv Universitas Indonesia

KATA PENGANTAR

Puji syukur penulis panjatkan kehadirat Allah SWT karena berkah dan rahmat-

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


v 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


vii Universitas Indonesia

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


viii Universitas Indonesia

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


ix Universitas Indonesia

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


x Universitas Indonesia

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 4.8.4 Manajemen masalah reaktif dan proaktif ........................................ 87 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


xi Universitas Indonesia

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


xii Universitas Indonesia

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


1 Universitas Indonesia

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.


2

Universitas Indonesia

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

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


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


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:


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:


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

literatur 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


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


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


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.


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)


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)


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


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)


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


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

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


27


Dalam menjalakan metodologi ini kita dapat menggunakan 4 alat bantu sebagai

berikut:

1. Rich Picture

Rich Picture adalah penggambaran nyata yang memungkinkan bermacam-

macam 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


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.


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.


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


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


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.


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


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.


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

Jäntti Kannamani Concise 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.

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.

Compare Hasil dari penelitian yang dilakukan memberikan rekomendasi tools, metode, struktur fungsi, dan rekomendasi implementasi kepada organisasi.

Memberikan penjabaran manfaat dari implementasi kerangka kerja ITIL dan pendekatan manajemen masalah proaktif dan reaktif.

Contrast Penelitian dilakukan pada ruang lingkup pemerintahan, yaitu administrasi perpajakan pemerintah Finlandia.

Penelitian dilakukan pada lingkup perusahaan TI kelas dunia.

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

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


Hubungan dengan penelitian ini

Penelitian Jantii dan penelitian yang akan dilakukan keduannya menggunakan best practice ITIL. Implementasi ITIL Jantti di perpajakan Finlandia memberikan beberapa hal yang menjadi tantangan dalam mengimplementasikan ITIL ke dalam service desk. Penulis akan menggunakan tantang dalam implementasi ITIL ini sebagai hal yang harus dicek apakah usulan perubahan proses pada manajemen operasi layanan sudah mengakomodasi tantangan tersebut.

Penelitian Kannamani dan penelitian yang akan dilakukan keduannya menggunakan best practice ITIL dan keduanya dilakukan pada perusahaan swasta. Penelitian Kannamani menjelaskan pendekatan manajemen masalah reaktif dan proaktif. Penulis akan menggunakan pendekatan yang dilakukan Kannamani sebagai masukan proses-proses yang akan diusulkan kepada organisasi.

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

Tabel 2.1 Perbandingan implementasi ITIL (Sambungan)


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.


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


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

perubahan 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


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 Peran Rujukan Permintaan yang masuk ke iCare itu apa saja?

Supervisor dan Agen

Manajemen event dan manajemen insiden pada ITIL v3 Service Operation

Permintaan yang masuk ke iCare itu melalui apa saja?

Supervisor dan Agen

Manajemen event dan manajemen insiden pada ITIL v3 Service Operation

Bagaimana iCare mengelola permintaan yang masuk dari sejak permintaan diterima hingga informasi kembali kepada pengguna?

Supervisor dan Agen

Manajemen insiden pada ITIL v3 Service Operation

Bagaimana iCare mengelola permintaan yang masuk yang terkait dengan operasional bisnis atau insiden?

Supervisor dan Agen

Manajemen insiden pada ITIL v3 Service Operation

Bagaimana mengelola masalah dari suatu insiden?

Supervisor, Analis, dan Agen

Manajemen masalah pada ITIL v3 Service Operation

Bagaimana mengelola permintaan yang bukan terkait masalah?

Supervisor, Analis, dan Agen

Pemenuhan permintaan pada ITIL v3 Service Operation

Bagaimana proses permintaan perubahan akses masuk?

Supervisor, dan Agen

Manajemen akses pada ITIL v3 Service Operation

Apakah fungsi dan aktivitas dari iCare?

Kepala departemen

Mengorganisir operasi layanan pada ITIL v3 Service Operation

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


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.

4.1 Data Wawancara

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


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

69) 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


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

89) 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 E-

Dora (lampiran-4 transkrip IR-78). Jika sudah ada permintaannya di E-

Dora 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 lain-

lain.

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.


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


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.


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 Analisis CATWOE Data Pendukung

Customers Seluruh pegawai yang menggunakan layanan

TI di Toyota Astra Finance

Lampiran-5 transkrip

R-102

Actors Tim IT Helpdesk Transkrip wawancara

dengan Supervisor

iCare, Agen IT

Helpdesk, dan IT

Analyst

Transformation Memberikan layanan dukungan TI bagi

operasional bisnis baik aplikasi, peralatan TI,

dan infrastruktur jaringan.


R-102

World view Menjaga performa bisnis dari gangguan yang

terkait dengan TI


R-102

Owners IT Development Department Head Lampiran-5 transkrip

R-101

Environmental

Constraints

Kewenangan layanan yang dimiliki tim IT

Helpdesk.

Transkrip wawancara

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


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

109), 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 R-

112).

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 Perbedaan Fungsi IT Helpdesk Tidak ada Kapasitas SDM BAF lebih banyak personil kapasitas operasi layanan BAF melayani lebih banyak cabang Jenis layanan BAF belum dilakukan kategorisasi Jalur komunikasi Sama kecuali Toyota Astra Finance ada SMS

dan BAF ada formulir kertas. Penanganan permintaan BAF langsung melakukan pencatatan di aplikasi

ticketing. TAFS melakukan pencatatan diakhir sebagai log.

Pemecahan masalah Tidak ada Perubahan hak akses Tidak ada

4.6.2 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


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.


77


Tabel 4.3 Perbandingan proses saat ini dengan operasi layanan ITIL v3

Manajemen event Manajemen Insiden Manajemen Masalah 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.

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.

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.

4.6.3 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


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.


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 Bagaimana aktivitas didunia nyata?

Komentar dan rekomendasi


Belum ada generator notifikasi event

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



Menjalankan aktivitas mengelola pemilahan event.



Menjalankan aktivitas pengangan event.


Sumber masuk insiden hanya berasal dari laporan pengguna. Pencatatan tidak dilakukan setelah menerima insiden. Dan belum ada pengecekan apakah insiden yang bersifat major.

Menambahkan sumber masuk insiden dari manajemen event. Melakukan pencatatan insiden setelah menerima insiden dan melakukan pengecekan apakah insiden yang bersifat major.

5. Melakukan penanganan insiden

Sudah ada eskalasi fungsional tetapi belum ada eskalasi hierarkis.

Menambahkan eskalasi hierarkis kepada manajemen.


Belum ada manajemen masalah proaktif.

Membuat manajemen masalah proaktif dan mengelolanya.

7. Mendeteksi masalah Pendeteksian masalah berasal dari laporan pengguna, manajemen insiden.

Menambahkan pendeteksian masalah yang berasal dari manajemen event, manajemen masalah proaktif, dan masalah yang berasal dari supplier/kontraktor.


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.

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


Aktivitas Bagaimana aktivitas didunia nyata?

Komentar dan rekomendasi


Belum ada known-error database Membuat known-error database dan mengelola known-error database.

10. Mengelola CMS Belum ada CMS Membuat CMS dan mengelola CMS


Penanganan efektivitas berada dilevel manajemen, belum ada peninjauan efektivitas penanganan secara mandiri oleh tim.

Melakukan peninjauan efektivitas oleh tim IT Helpdesk.

12. Monitor/pengawasan

Pengawasan sudah dilakukan oleh manajemen.

Sudah sesuai.


Tindakan dari hasil pengawasan dilakukan oleh manajemen dengan memberikan dukungan kepada IT Helpdesk.

Sudah sesuai.

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.

Tabel 4.4 Perbandingan model konseptual dengan dunia nyata (Sambungan)


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 Terhadap budaya perusahaan


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

Sejalan dengan nilai Care. Dengan membuat generator notifikasi event maka gangguan bisa langsung diproses tanpa menyulitkan pengguna untuk melapor terlebih dahulu.


Menjalankan aktivitas mengelola pemilahan event.

Sejalan dengan nilai Fast. Karena pemilahan event mempercepat proses penanganan event.


Menjalankan aktivitas pengangan event.

Sejalan dengan nilai Care. Dengan membuat melakukan penanganan event maka gangguan bisa langsung diproses tanpa menyulitkan pengguna untuk melapor terlebih dahulu.


85




Menambahkan sumber masuk insiden dari manajemen event. Melakukan pencatatan insiden setelah menerima insiden dan melalkukan pengecekan apakah insiden yang bersifat major.

Sejalan dengan nilai Care. Dengan menambah sumber masuk insiden melalui manajemen event maka gangguan bisa langsung 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 penanganan insiden

Menambahkan eskalasi hierarkis kepada manajemen.

Proses eskalasi hierarkis jika berada di sisi IT helpdesk memudahkan pengguna, sejalan dengan value simple.


Membuat manajemen masalah proaktif dan mengelolanya.

Dengan memiliki dan mengelola manajemen masalah proaktif maka masalah dapat diselesaikan sebelum muncul, sejalan dengan value Care.

7. Mendeteksi masalah Menambahkan pendeteksian masalah yang berasal dari manajemen event, manajemen masalah proaktif, dan masalah yang berasal dari supplier/kontraktor.

Penambahan informasi pedeteksian masalah sejalan dengan value Care.


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.

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.

Tabel 4.5 Kesesuaian aktivitas model dengan budaya perusahaan (Sambungan)


86




Membuat known-error database dan mengelola known-error database.

Pengelolaan known-error database mempercepat proses investigasi penangan masalah sehingga sejalan dengan value Fast.

10. Mengelola CMS Membuat CMS dan mengelola CMS

Pengelolaan CMS dapay mempercepat proses diagnosa masalah dikemudian hari sehingga sejalan dengan value Fast.


Melakukan peninjauan efektivitas oleh tim IT Helpdesk.

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.

12. Monitor/pengawasan

Sudah sesuai. -


Sudah sesuai. -

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

Tabel 4.5 Kesesuaian aktivitas model dengan budaya perusahaan (Sambungan)


87


Tabel 4.6 Saran dari challenges implementasi ITIL

Chalenges implementasi ITIL

Kondisi pada model konseptual Saran

klarifikasi atas klasifikasi dari permintaan support yang jelas.

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

Pada model konseptual pencatatan insiden dan masalah dilakukan oleh IT Helpdesk.

Memberikan pelatihan dan petunjuk pada aplikasi pencatatan.

Ide peningkatan tidak dicatat secara sistematis ke dalam sistem service desk

Model menyediakan manajemen masalah proaktif untuk mencari ide peningkatan layanan tetapi tidak menyediakan pencatatan ide peningkatan layanan.

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.


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 kemudian menjalankan aktivitas mengelola generator notifikasi event.

Ya, sebagian

Implementasi teknis dibicarakan lebih lanjut. Saat ini IT Helpdesk lebih fokus kepada alert dulu. Belum mengejar yang autoresponse.

Menjalankan aktivitas mengelola pemilahan event dan menjalankan aktivitas pengangan event.

Ya Penanganan dilakukan manual dengan working instruction.

Menambahkan sumber informasi masuk insiden dari manajemen event.

Ya -

Melakukan pencatatan insiden setelah menerima insiden dan melakukan pengecekan apakah insiden yang bersifat major.

Ya Akan dilakukan setelah ada dengan peralatan kerja.

Menambahkan eskalasi hierarkis dari IT Helpdesk ke manajemen.

Tidak Masih khawatir keakuratan informasi masalah dan pemahaman masalah teknis di sisi manajemen. Eskalasi dilakukan manual melalui supervisor.

Membuat manajemen masalah proaktif dan mengelolanya. Melakukan aksi preventif pada manajemen masalah proaktif, misalnya memberikan pelatihan dan petunjuk pada aplikasi pencatatan.

Ya Akan dilakukan setelah ada peralatan/tools yang memadai dan kategorisasi yang jelas.

Menambahkan pendeteksian masalah yang berasal dari manajemen event, manajemen masalah proaktif, dan masalah yang berasal dari supplier/kontraktor.

Ya Dilakukan setelah ada manajement event dan manajemen proaktif.

Membuat pencatatan yang berbeda antara masalah dan insiden dan membuat tautan antar insiden sehingga dapat diketahui bahwa insiden berulang.

Ya Sangat setuju.

Membuat prioritas penanangan masalah.

Ya Sangat setuju.


91


Usulan perubahan Keputusan Komentar Membuat CMS dan mengelola CMS kemudian menggunakan CMS dalam investigasi dan diagnosa.

Tidak Tidak dalam waktu dekat, karena penyusunan data CMS awal yang memakan banyak waktu dan sumber daya, termasuk pengumpulan informasi dari departemen infrastuktur.

Membuat known-error database dan mengelola known-error database kemudian menggunakan known-error database untuk mencari solusi jangka pendek.

Ya Ada pandangan untuk dibagikan kepada pengguna untuk error yang non teknis.

Melakukan peninjauan efektivitas penanganan oleh tim IT Helpdesk.

Ya Akan dilakukan apabila sudah 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:

Tabel 4.7 Saran dari FGD untuk usulan perubahan (Sambungan)


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


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.


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.


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



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


98


Untuk memperjelas proses yang dikelola antar peran berikut adalah gambar

BPMN dari proses manajemen insiden.

Gambar 4.11 BPMN manajemen insiden


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


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


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.


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


102


Gambar 4.15 BPMN manajemen masalah


TI membuat suatu known-error database. Semua masalah atau error yang

sudah diketahui solusi jangka pendeknya dicatat pada basisdata ini. Solusi


103


jangka pendek yang ada dapat diperbaharui oleh tim IT Helpdesk yang sedang

melakukan penanganan jika solusi lain yang lebih efektif dan efisien.


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.


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 Fitur Manajemen event Mendeteksi event Manajemen event Memberikan notifikasi kepada agen Manajemen event Menerima umpan balik dari sistem lain Manajemen event Mentransfer informasi event ke sistem lain Manajemen event Melakukan pencatatan event dan aksi agen Manajemen event Meminta agen untuk melalukan peninjauan

efektivitas penanganan Manajemen insiden Mencatat insiden yang masuk Manajemen insiden Menerima umpan balik dari sistem lain Manajemen insiden Mentransfer informasi ke sistem lain Manajemen insiden Memisahkan insiden berdasarkan kategori dan

tingkat majority Manajemen insiden Melakukan eskalasi kepada supervisor/2nd level Manajemen insiden Mencatat penanganan insiden yang dilakukan Manajemen masalah proaktif

Memberikan laporan trend event / insiden / masalah

Manajemen masalah proaktif

Menerima inisiatif dari tim IT Helpdesk


Menerima umpan balik dari sistem lain


Mentransfer informasi event ke sistem lain

Manajemen masalah Menerima umpan balik dari sistem lain Manajemen masalah Mentransfer informasi event ke sistem lain Manajemen masalah Melakukan pencatatan masalah Manajemen masalah Memberikan kategori dan prioritas masalah Manajemen masalah Melakukan eskalasi kepada 2nd level/vendor Manajemen masalah Mencatat penanganan masalah yang dilakukan Known-Error Database

Mencatat error dan resolusi yang ada

Known-Error Database

Melakukan pencarian error dan resolusi

Manajerial report 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 Fitur Komentar Manajemen event

Mendeteksi event Belum ada, perlu ditambahkan modifikasi

Manajemen event

Memberikan notifikasi kepada agen Ada

Manajemen event


Belum ada, perlu ditambahkan modifikasi

Manajemen event


Ada

Manajemen event

Melakukan pencatatan event dan aksi agen

Ada

Manajemen event

Meminta agen untuk melalukan peninjauan efektivitas penanganan

Ada

Manajemen insiden

Mencatat insiden yang masuk Ada

Manajemen insiden



Manajemen insiden

Mentransfer informasi ke sistem lain Ada

Manajemen insiden

Memisahkan insiden berdasarkan kategori dan tingkat majority

Ada

Manajemen insiden

Melakukan eskalasi kepada supervisor/2nd level

Ada

Manajemen insiden

Mencatat penanganan insiden yang dilakukan

Ada


Memberikan laporan trend event / insiden / masalah

Ada


Menerima inisiatif dari tim IT Helpdesk

Ada





106


Sistem Fitur Komentar Manajemen masalah proaktif



Manajemen masalah


Ada

Manajemen masalah


Ada

Manajemen masalah

Melakukan pencatatan masalah Ada

Manajemen masalah

Memberikan kategori dan prioritas masalah

Ada

Manajemen masalah

Melakukan eskalasi kepada 2nd level/vendor

Ada

Manajemen masalah

Mencatat penanganan masalah yang dilakukan

Ada


Mencatat error dan resolusi yang ada Ada


Melakukan pencarian error dan resolusi

Ada

Manajerial report

Memberikan laporan-laporan kinerja IT Helpdesk kepada manajerial

Ada

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

Tabel 4.9 Tabel kesesuaian fitur aplikasi Redmine (Sambungan)


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


108


4.12.2 Draft SOP Manajemen Insiden IT Helpdesk

1. Tujuan


panduan pada proses penanganan insiden di IT Helpdesk agar tercipta tertib

administrasi dalam pelaksanaan prosedur penanganan insiden. Dengan


pada penanganan insiden pada bagian IT Helpdesk.

2. Ruang lingkup


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)


110




111



4.12.3 Draft SOP Manajemen Masalah Proaktif IT Helpdesk

1. Tujuan


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


b. Prosedur ini meliputi manajemen masalah proaktif pada IT Helpdesk.


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


panduan pada proses penanganan masalah di IT Helpdesk agar tercipta tertib

administrasi dalam pelaksanaan prosedur penanganan masalah. Dengan


pada penanganan masalah pada bagian IT Helpdesk.

2. Ruang lingkup



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


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

Metrik

Manajemen Event Jumlah event per kategori. Manajemen Event Jumlah event per signifikansi. Manajemen Event 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 Jumlah dan persentase dari event yang berulang atau terduplikasi. Manajemen Event Jumlah dan persentase dari event yang mengindikasikan isu

kinerja. Manajemen Event Jumlah dan persentase dari event yang mengindikasikan potensi

isu ketersediaan. Manajemen Event Jumlah dan persentase dari tiap event per platform atau aplikasi. Manajemen Event Jumlah dan rasio event dibandingkan dengan jumlah insiden. Manajemen Insiden Total jumlah insiden. Manajemen Insiden Total Insiden yang didetailkan pada status insiden. Manajemen Insiden Jumlah insiden saat ini yang backlog. Manajemen Insiden Jumah dan persentase insiden major. Manajemen Insiden Rata-rata waktu yang dibutuhkan untuk mencapai resolusi

insiden. Manajemen Insiden Persentase insiden yang ditangani yang masih didalam waktu

respon yang disepakati. Manajemen Insiden Biaya rata-rata per insiden. Manajemen Insiden Jumlah insiden yang terbuka kembali (reopened) dibandingkan

dengan persentase total. Manajemen Insiden Jumlah dan persentase insiden yang tidak ditugaskan dengan

benar. Manajemen Insiden Jumlah dan persentase insiden yang memiliki kategori yang tidak

tepat. Manajemen Insiden Persentase insiden yang diselesaikan tanpa eskalasi (first point

contact).


117



Metrik

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 Jumlah total masalah yang tercatat dalam suatu periode. Manajemen Masalah Persentase masalah yang diselesaikan dalam target SLA. Manajemen Masalah Jumlah dan persentase masalah yang melebihi target waktu

resolusi. Manajemen Masalah Jumlah backlog masalah dan trend masalah. Manajemen Masalah Rata-rata biaya penanganan masalah. Manajemen Masalah Jumlah masalah major. Manajemen Masalah Persentase dari peninjauan masalah major yang berhasil

dilakukan. Manajemen Masalah Jumlah Known-Error yang ditambahkan ke dalam Kown-Error

Database. Manajemen Masalah Persentase akurasi dari Kown-Error Database. Manajemen Masalah Persentase peninjauan masalah major yang selesai dilakukan dan

tepat waktu. Pemenuhan Permintaan

Jumlah permintaan layanan.

Pemenuhan Permintaan

Permintaan layanan pada tiap tahap.


Jumlah backlog saat ini.


Waktu rata-rata penyelesaian penanganan tiap jenis permintaan layanan.


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


Rata-rata biaya per permintaan layanan.


Tingkat kepuasan pelanggan dari penanganan permintaan melalui survei.

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

individual. Manajemen Akses Jumlah insiden yang membutuhkan reset hak akses. Manajemen Akses Jumlah insiden yang disebabkan kesalahan pemberian akses. Manajemen Masalah Proaktif

Jumlah inisatif yang dicatat dalam suatu periode

Tabel 4.10 Tabel metrik pengukuran efektivitas dan efisiensi operasi layanan (Sambungan)


118



Metrik

Manajemen Masalah Proaktif

Jumlah inisatif yang berhasil diterapkan

Efficacy Kepuasan dukungan layanan TI melalui survei Effectiveness 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.

Tabel 4.10 Tabel metrik pengukuran efektivitas dan efisiensi operasi layanan (Sambungan)


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.


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.


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,


125


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

perusahaan 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

(Lanjutan)


126


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

(Lanjutan)


127


Lampiran 2 Transkrip Wawancara Dengan agen IT Helpdesk

Narasumber : DRO

Jabatan Narasumber : IT Helpdesk Support


Tanggal Wawancara : 15 November 2014

Tempat Wawancara : Kantor Cabang Kelapa Gading


Id Ide Transkrip wawancara I-1 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?

R-1 Oke boleh ya Pak Bayu, selamat siang nama saya DRO dari iCare. Ada yang bisa dibantu silahkan ditanyakan.

I-2 2 Di iCare posisinya Pak DRO sebagai apa Pak? R-2 2 Saya sebagai IT Helpdesk support. kalau dibilang di iCare itu kita

sebagai first level-nya sih. I-3 1 Di iCare permintaan yang masuk itu apa saja Pak DRO? R-3 1 Biasanya ada 3 permintaan yang masuk ke iCare itu biasanya request,

informasi dan problem I-4 1 Request itu maksudnya gimana Pak? R-4 1 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.

I-5 1 Itu Berarti semacam permintaan bantuan gitu ya Pak? R-5 1 Iya. I-6 1 Oke, Kalau infomasi Pak? R-6 1 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.

I-7 1 Kalau problem? R-7 1 Problem, biasanya kalau terkait di confins ada aplikasi error ya,


128


Id Ide Transkrip wawancara misalnya setelah maintenance, user ada aplikasi, naikin aplikasi kadang-kadang 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.

I-8 Ehmm. Begitu berarti ada 3 jenis? R-8 Iya I-9 3 lalu permintaan-permintaan tadi itu masuknya melalui apa saja Pak? R-9 3 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.

I-10 3 Ok, Berarti iCare punya 1 telepon sendiri ya pak. Punya mobile phone sendiri untuk berkomunikasi, SMS dan BBM ya pak ya?

R-10 3 iya. I-11 4 Kemudian bagaimana sih caranya iCare ini mengelola permintaan yang

masuk, sejak dari permintaan ini diterima sampai diinformasikan lagi pada pengguna.

R-11 4 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.

I-12 Berarti yang mengabari terakhir iCare ya pak ya? R-12 Iya I-13 5 Lalu bagaimana cara iCare mengelola permintaan yang masuk? Tapi

yang terkait dengan opersional bisnis atau saya sebutnya sebagai insiden pak ?

R-13 5 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.

I-14 5 Oo, dengan GAL. Berarti di first level tidak menangani yang insiden ya pak. Semuanya di GAL.

R-14 Iya. I-15 Nanti setelah Pak GAL selesai, Pak GAL menghubungi langsung atau

bagaimana?

(Lanjutan)


129


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,

(Lanjutan)


130


Id Ide Transkrip wawancara berarti sebetulnya ada 1 lagi ya pak yaitu dengan aplikasi Edora dimana isinya ada URF dan CDR?

R-23 Iya I-24 5 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?

R-24 5 Sampai saat ini sih kayak nya belum ada. I-25 5 O belum ada ya. Kemudian ada panduan formal gak Pak? untuk

mengenai insiden yang sifatnya critical? dan prioritasnya bagaimana gitu? Sudah ada panduan formalnya?

R-25 5 Belum ada Juga. I-26 6 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?

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

I-27 6 Selama dia dikabari bahwa ini membutuhkan waktu jangka panjang, ada solusi jangka pendek juga gak pak?

R-27 6 Untuk solusi jangka pendek biasanya ada. I-28 6 Ada, kalau ada diberikan ya pak ya? R-28 6 Iya, diberikan kita kasih tau juga . I-29 6 Kalau tidak ada? R-29 6 Diinformasikan kalau ini pasti membutuhkan jangka waktu yang panjang

jadi ditunggu saja oleh user. Biasanya seperti itu. I-30 5 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?

R-30 5 Belum ada, masih sama. I-31 10 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

R-31 10 Untuk database belum ada. I-32 Belum ada ya pak, semua masih by manual ya, dipikiran masing-masing. R-32 Iya masih manual I-33 6 Satu lagi Pak, ada bank data lagi gak pak? yang terkait pencatatan error

(Lanjutan)


131


Id Ide 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?

R-33 6 Sampai saat ini belum ada, biasanya kita langsung ingatannya kita bagaimana cara menyelesaikan masalah itu sih. belum ada dibuat data bank seperti itu

I-34 Oke Berarti masih dikepala personil iCare masing-masing ya Pak? R-34 Iya I-35 Oke, terima kasih banyak waktunya Pak DRO R-35 Iya, sama-sama Pak. I-36 Selamat siang Pak. R-36 Selamat Siang.

Daftar Ide:

Nomor ide Ide / gagasan 1 Layanan iCare 2 Role 3 iCare information channel 4 Event management process 5 Incident management process 6 Problem management process 7 Request Fulfilment 8 Access Management 9 iCare tools 10 CMDB

(Lanjutan)


132


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

Narasumber : JSE

Jabatan Narasumber : IT Developer / Analyst




Id Ide Transkrip Wawancara I-37 Selamat Sore Ibu JSE, Saya Bayu dari MTI UI, mau bertanya sedikit

tentang proses pengelolaan masalah di iCare. Bisa minta waktunya sebentar?

R-37 Sore, Silakan I-38 2 Ok, Ibu JSE di Toyota Astra finances, Ibu JSE Sebagai apa? R-38 2 IT developer / analis. I-39 2 Analis. Ok. Analis ini berarti membantu penyelesaikan second level ya

Bu JSE ya? R-39 Iya, betul. I-40 6 Oke, mau nanya Bu JSE, bagaimana pengelolaan masalah dari suatu

insiden yang termasuk didalamnya proses pemecahan masalahnya gitu? R-40 6 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.

I-41 6 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?

R-41 6 Untuk saat ini sih belum ada ya. I-42 O, belum ada ya? R-42 Iya. I-43 10 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?

R-43 10 Untuk yang mencatat semuanya sih belum ada I-44 Belum ada ya?


133


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

I-49 6 Jadi di ingat-ingat dulu, jika sudah pernah merasa sudah pernah mengatasi hal itu baru dicari ya.

R-49 6 Iya I-50 6 Tapi itu detail ya bu ya? jadi ada masalahnya apa, cara penyelesaiannya

apa? Ada semua disitu ? R-50 6 Belum, belum ada struktur yang harusnya seperti apa sih, cuman

tergantung orang yang pencatatan masing-masing I-51 6 berarti free text R-51 6 iya free text I-52 7 Ok, pertanyaaan selanjutnya bagaimana mengelola permintaan yang

tidak terkait masalah atau insiden. Misalnya untuk permintaan untuk reporting atau ada perubahan tampilan dan sebagainya?

R-52 7 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.

I-53 7 O dari URFA tadi lanjutannya gimana ibu, setelah user isi URFA lalu? R-53 7 User perlu approval ke atasannya setelah itu nanti masuk ke IT dept

head, lalu jalurnya nanti di tentukan, disampaikan ke PIC masing-masing.

I-54 9 PIC yang akan melakukan perubahan itu ya. URFA ini berarti ada suatu aplikasinya tersendiri ya Bu?

R-54 9 Ada-ada, terpisah sendiri I-55 9 Itu sama dengan yang di Edora itu tidak sih bu? yang dipakai first level

sama ya?

(Lanjutan)


134


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

R-59 1 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.

I-60 1 Berarti email bisa saja dari user langsung ke second level? R-60 1 Iya bisa email langsung I-61 Ok, Bu terima kasih banyak atas waktunya Bu JSE R-61 Sama-sama. I-62 Terima Kasih.

Daftar Ide:

Nomor ide Ide / gagasan 1 Layanan iCare 2 Role 3 iCare information channel 4 Event management process 5 Incident management process 6 Problem management process 7 Request Fulfilment 8 Access Management 9 iCare tools 10 CMDB

(Lanjutan)


135


Lampiran 4 Transkrip Wawancara Dengan Supervisor IT Helpdesk

Narasumber : GAL

Jabatan Narasumber : IT Developer / Analyst




Id Ide Transkrip Wawancara I-63 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?

R-63 Selamat sore mas bayu, gak pa pa mas bayu silakan. I-64 2 Maaf sebelumnya Pak GAL, di iCare posisinya sebagai apa Pak? R-64 2 Saya sebagai supervisor disana, jadi sebagai pengawas operasional sehari-

hari dari setiap beraktivitas dan task-task yang masuk ditempat kami. Itu memang PIC-nya di Saya. Saya bertanggung jawab terhadap penyelesaiannya, monitoringnya, seperti itu.

I-65 1 Oke Pak, Pertanyaan pertama ya Pak ya. Permintaan yang masuk ke iCare itu apa aja?

R-65 1 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 level-nya 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 meng-create 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


136


Id Ide 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.

I-66 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.

R-66 3 Ya betul, aplikasinya ini terpisah. Dia berdiri sendiri. Jadi permintaan ini secara formal kita sistem sistemasikan di aplikasi tersebut.

I-67 3 Permintaan yang masuk ke iCare itu melalui apa saja ya Pak ya? R-67 3 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.

I-68 Berarti ada handphone yang memang khusus dipergunakan untuk komunikasi di iCare ya pak ya?

R-68 Betul, jadi kami memang menyediakan 1 dedicated handphone yang kami taruh di ruangan helpdesk support.

I-69 4 Lalu, bagaimana iCare mengelola permintaan yang masuk sejak permintaan itu diterima hingga informasinya kembali kepada user?

R-69 4 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.

(Lanjutan)


137


Id Ide 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.

I-70 4 Pencatatannya melalui apa Pak? R-70 4 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.

I-71 4 Aplikasi ini kalau tidak salah Issue log ya pak ya? R-71 4 Betul nama aplikasinya issue log. I-72 Kemudian tadi ada disebutkan ada identifikasi pelayanan yang diterima,

disini identifikasi itu terkait dengan batasan, wewenang dan keahlian ya? R-72 Betul. I-73 5 Oke, bagaimana iCare mengelola permintaan yang masuk yang terkait

dengan operasional bisnis atau biasa yang disebur dengan insiden? R-73 5 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

I-74 Saat masalahnya sudah selesai, nanti prosesnya bagaimana Pak? Sudah dikerjakan oleh second level misalnya?

R-74 Maksudnya? I-75 5 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?

R-75 5 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.

I-76 Semua second level punya email iCare? R-76 5 Tidak semua second level, hanya beberapa orang yang memiliki yang,

apa, di email-nya itu akun email [email protected]

(Lanjutan)


138


Id Ide Transkrip Wawancara I-77 7 Lalu bagaimana mengelola permintaan yang tidak terkait dengan insiden?

Jadi misalnya permintaan untuk membuat reporting, permintaan data dan sebagainya?

R-77 7 Permintaan yang tidak terkait insiden seperti yang mas bayu bilang reporting, permintaan, apa tadi yang pertama?

I-78 7 Permintaan data, reporting. R-78 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.

I-79 7 URFA itu yang melalui edora ya Pak ya? R-79 7 Betul, aplikasinya masih di edora I-88 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?

R-88 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.

I-89 6 Pengelolaannya berarti masih by email ya pak ya? Belum ada sitem? R-89 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.

I-90 6 Tapi dimasukkan ke dalam issue log sebagai pencatatan? R-90 6 Betul, dimasukkan ke dalam issues log


139


Id Ide Transkrip Wawancara I-91 8 Oke, lalu bagaimana iCare mengelola permintaan terkait dengan

perubahaan akses? Untuk perubahan rotasi? Atau bagaimana begitu. R-91 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.

I-92 8 Melalui Edora lagi ya Pak ya? R-92 8 Betul, edora lagi. I-93 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?

R-93 Saat ini kami belum memiliki prioritas seperti itu. I-94 Oke, jadi untuk pemecahan masalah pun belum ada kategorisasinya ya

pak. Misalnya untuk masalah ini maka perlu sekian analis, untuk yang ini maka vendor.

R-94 Belum, belum. I-95 Belum ada panduaanya? R-95 Belum ada prosedur sampai ke tahap itu. I-96 Oke, untuk panduan, tadi kan ada terkait wewenang juga ya pak ya? R-96 Ya, Betul I-97 Untuk panduaan wewenangnya berarti keputusannya ada di supervisor?

Atau ada panduan secara yang terdokumentasi? R-97 Tidak untuk secara prosedur, dokumentasi kami masih belum banyak dan

rasanya kalau buat wewenang seperti itu masih ada ditempat saya. I-98 Baik pak GAL terima kasih banyak atas waktunya selamat sore. R-98 Selamat sore, terima kasih, sama-sama mas bayu .

Daftar Ide:

Nomor ide Ide / gagasan 1 layanan iCare 2 Role 3 iCare information channel 4 event management process 5 incident management process 6 problem management process 7 Request Fulfilment 8 Access Management 9 iCare tools

(Lanjutan)


140


Lampiran 5 Transkrip Wawancara dengan IT Development Head

Narasumber : TSU

Jabatan Narasumber : IT Development Department Head




Id Ide Transkrip Wawancara I-99 Halo, Selamat Pagi Pak TSU, Saya Bayu dari MTI UI mau minta

waktunya sebentar bisa? R-99 Pagi Bayu, Bisa, silakan. I-100 2 Pak TSU, di Toyota Astra Finances sebagai IT Development Head ya? R-100 2 Ya, Saya TSU bekerja di Toyota Astra Finance dan bertanggung jawab di

IT Development Department dan kemudian saya sudah bekerja kurang lebih 8 tahun

I-101 2 Oke Pak terkait dengan iCare disini pak TSU fungsinya seperti apa? R-101 2 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.

I-102 11 Oke, terima kasih Pak. Nah, saya ada beberapa pertanyaan, yang pertama apakah fungsi dan aktivitas dari iCare?

R-102 11 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.

I-103 12 Oke Pak. Apakah ada dukungan dari manajemen Pak untuk operasi layanan iCare ini? Kalau ada seperti apa saja Pak?


141


Id Ide Transkrip Wawancara R-103 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 people-nya, kapasitas dari people-nya terus kita tingkatkan baik melalui training, trainingnya baik yang sifatnya technical maupun yang soft skill.

I-104 12 Pernah ada ini tidak Pak? Terkait dengan dukungan manajemen tadi, pernah ada misalnya training, training yang sifatnya ke personil-personil iCare itu?

R-104 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.

I-105 13 Oke, bagaimana budaya perusahaan di Toyota Astra Finances dan implikasinya kepada operasi layanan iCare?

R-105 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.

I-106 14 Oke Pak. Apakah ada kebijakan-kebijakan perusahaan yang mempengaruhi operasi layanan iCare?

(Lanjutan)


142


Id Ide Transkrip Wawancara R-106 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.

I-107 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?

R-107 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 .

I-108 Oke mungkin saat ini itu dulu Pak TSU terima kasih banyak atas waktunya

R-108 Terima Kasih bayu.

Nomor ide ide/gagasan 2 Role 11 Fungsi iCare 12 Dukungan manajemen kepada iCare 13 Pengaruh Budaya perusahaan kepada iCare 14 Pengaruh Kebijakan perusahaan kepada iCare

(Lanjutan)


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 Ide Transkrip Wawancara I-109 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?

R-109 13 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 IT Helpdesk apakah dalam 1 lokasi atau tersebar? Berapa cabang yang dilayani?

R-110 14 IT Helpdesk dikumpulkan dalam 1 ruangan yang melayani 188 cabang di seluruh Indonesia

I-111 Permintaan yang masuk ke IT Helpdesk itu apa saja? R-111 15 • 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

I-112 Permintaan yang masuk ke IT Helpdesk itu melalui apa saja? R-112 16 • Email

• Telepon • Formulir

I-113 Bagaimana IT Helpdesk mengelola permintaan yang masuk dari sejak permintaan diterima hingga informasi kembali kepada pengguna?


144


R-113 17 • 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.

I-114 Bagaimana IT Helpdesk mengelola permintaan yang masuk yang terkait dengan operasional bisnis atau yang disebut dengan insiden?

R-114 18 • Mencatatnya pada aplikasi manajemen tiket (Mantis) • Menginformasikan isu tersebut kepada pihak-pihak terkait dan manajemen melalui email • Memonitor perkembangan melalui aplikasi manajemen tiket

I-115 Bagaimana mengelola masalah dari suatu insiden, termasuk didalamnya proses pemecahan masalah?

R-115 19 • 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

I-116 Bagaimana mengelola permintaan yang tidak terkait masalah atau insiden?

R-116 20 • 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

I-117 Bagaimana mengelola permintaan dari perubahan akses? R-117 21 • 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 Ide/gagasan 13 fungsi IT helpdesk BAF 14 skala IT Helpdesk BAF 15 layanan IT Helpdesk BAF 16 Saluran informasi IT Helpdesk BAF 17 pengelolaan permintaan IT Helpdesk BAF 18 pengelolaan insiden IT Helpdesk BAF

(Lanjutan)


145


Nomor ide Ide/gagasan 19 pemecahan masalah di IT Helpdesk BAF 20 pemenuhan permintaan di IT Helpdesk BAF 21 perubahan akses di IT Helpdesk BAF

(Lanjutan)


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


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

(Lanjutan)


151


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.

(Lanjutan)


152


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.

(Lanjutan)


153


Lampiran 9 Contoh SOP Toyota Astra Finance


154


(Lanjutan)


155


(Lanjutan)


156


(Lanjutan)


UNIVERSITAS INDONESIA MANAJEMEN OPERASI LAYANAN...

Documents

Transcript of UNIVERSITAS INDONESIA MANAJEMEN OPERASI LAYANAN...