UNIVERSITAS INDONESIA MANAJEMEN OPERASI LAYANAN...
Transcript of 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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
3
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
4
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
5
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
6
Universitas Indonesia
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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
7
Universitas Indonesia
“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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
8
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
9 Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
10
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
11
Universitas Indonesia
(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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
12
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
13
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
14
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
15
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
16
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
17
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
18
Universitas Indonesia
Gambar 2.3 Alur proses manajemen event Sumber: OGC (2007)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
19
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
20
Universitas Indonesia
Gambar 2.4 Alur proses manajemen insiden Sumber: OGC (2007)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
21
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
22
Universitas Indonesia
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).
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
23
Universitas Indonesia
Gambar 2.5 Alur proses manajemen masalah Sumber: OGC (2007)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
24
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
25
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
26
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
27
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
28
Universitas Indonesia
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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
29
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
30
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
31
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
32
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
33
Universitas Indonesia
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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
34
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
35
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
36
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
37
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
38
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
39
Universitas Indonesia
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-
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
40
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
41
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
42
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
43
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
44
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
45
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
46
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
47
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
48
Universitas Indonesia
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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
49
Universitas Indonesia
Gambar 2.10 Kerangka Berpikir
Kerangka berpikir ini menjawab pertanyaan penelitian berkaitan dengan
manajemen operasi layanan IT Helpdesk di Toyota Astra Finance.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
50 Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
51
Universitas Indonesia
Gambar 3.11 Metodologi penelitian
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
52
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
53
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
54
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
55
Universitas Indonesia
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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
56
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
57
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
58 Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
59
Universitas Indonesia
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).
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
60
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
61
Universitas Indonesia
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).
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
62
Universitas Indonesia
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”.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
63
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
64
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
65
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
66
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
67
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
68
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
69
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
70
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
71
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
72
Universitas Indonesia
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.
Lampiran-5 transkrip
R-102
World view Menjaga performa bisnis dari gangguan yang
terkait dengan TI
Lampiran-5 transkrip
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
73
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
74
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
75
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
76
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
77
Universitas Indonesia
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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
78
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
79
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
80
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
81
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
82
Universitas Indonesia
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
1. Mengelola generator notifikasi event
Belum ada generator notifikasi event
Membuat generator notifikasi event kemudian menjalankan aktivitas mengelola generator notifikasi event.
2. Mengelola pemilahan event
Belum ada generator notifikasi event
Menjalankan aktivitas mengelola pemilahan event.
3. Melakukan penanganan event
Belum ada generator notifikasi event
Menjalankan aktivitas pengangan event.
4. Menerima insiden yang masuk
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.
6. Mengelola manajemen masalah proaktif
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.
8. Melakukan penanganan masalah
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
83
Universitas Indonesia
Aktivitas Bagaimana aktivitas didunia nyata?
Komentar dan rekomendasi
9. Mengelola known-error database
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
11. Meninjau efektivitas penanganan
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.
13. Mengambil tindakan
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
84
Universitas Indonesia
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
1. Mengelola generator notifikasi event
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.
2. Mengelola pemilahan event
Menjalankan aktivitas mengelola pemilahan event.
Sejalan dengan nilai Fast. Karena pemilahan event mempercepat proses penanganan event.
3. Melakukan 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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
85
Universitas Indonesia
Aktivitas komentar dan rekomendasi Terhadap budaya perusahaan
4. Menerima insiden yang masuk
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.
6. Mengelola manajemen masalah proaktif
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.
8. Melakukan penanganan masalah
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
86
Universitas Indonesia
Aktivitas komentar dan rekomendasi Terhadap budaya perusahaan
9. Mengelola known-error database
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.
11. Meninjau efektivitas penanganan
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. -
13. Mengambil tindakan
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
87
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
88
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
89
Universitas Indonesia
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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
90
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
91
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
92
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
93
Universitas Indonesia
pengguna yang mencurigakan, dan sebagainya. Sistem manajemen event
memantau system atau menerima respon dari system lain. Event dideteksi
kemudian meneruskan notifikasi kepada agen. Sistem manajemen event
mencatat semua event yang diteruskan kepada agen dan juga mencatat pilihan
respon yang dilakukan oleh agen.
2. Mengelola pemilahan event
Event yang diteruskan oleh sistem manajemen event diperiksa oleh agen
apakah perlu direspon atau tidak. Jika tidak perlu direspon maka agen
memilih untuk merespon bahwa event sudah diinformasikan tanpa ada respon
yang perlu dilakukan. Jika perlu direspon maka agen menentukan apakah ini
ditangani secara langsung atau dimasukan sebagai kategori insiden, masalah,
atau permintaan untuk melakukan perubahan. Sistem manajemen event
mencatat pilihan aksi agen tersebut.
3. Melakukan penanganan event
Event yang dipilih untuk direspon secara langsung maka langsung dikerjakan
oleh agen. Setelah selesai agen menuliskan aksi yang dilakukan pada
manajemen event. Jika event diteruskan sebagai insiden, masalah, atau
permintaan perubahan maka sistem manajemen event meneruskan informasi
ke sistem yang lain. Status event tetap dalam proses penyelesaian sampai
sistem lain memberikan umpan balik kepada manajemen event bahwa event
yang diteruskan sudah selesai ditangani.
Setelah event selesai ditangani baik diteruskan ke sistem lain atau ditangani
agen langsung maka manajemen event memberikan notifikasi kepada agen
untuk melakukan peninjauan apakah aksi yang diberikan efektif atau tidak.
Jika tidak efektif maka respon pilihan kembali terbuka untuk dikerjakan
kembali atau diteruskan ke sistem lain. Tetapi jika sudah selesai maka event
diubah statusnya sebagai sudah selesai.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
94
Universitas Indonesia
Gambar 4.8 Proses manajemen event
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
95
Universitas Indonesia
Proses pada gambar 4.8 hanya melibatkan satu peran saja. Apabila
digambaran dalam Business Process Model Notation (BPMN) maka
didapatkan gambar berikut.
Gambar 4.9 BPMN manajemen event
4. Menerima insiden yang masuk
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
96
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
97
Universitas Indonesia
Gambar 4.10 Proses manajemen insiden
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
98
Universitas Indonesia
Untuk memperjelas proses yang dikelola antar peran berikut adalah gambar
BPMN dari proses manajemen insiden.
Gambar 4.11 BPMN manajemen insiden
6. Mengelola manajemen masalah proaktif
TI membuat suatu sistem manajemen masalah proaktif yang berisi laporan
trend event, insiden, dan masalah yang terjadi. Supervisor menganalisa terkait
tren dan masalah-masalah potensial yang berdampak besar kepada bisnis
(aksi preventif) sebagai inisiatif perbaikan. Sistem manajemen masalah dapat
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
99
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
100
Universitas Indonesia
7. Mendeteksi masalah
Agen masalah terdeteksi masalah yang masuk dari laporan pengguna melalui
manajemen insiden, dari sistem manajemen event, dari manajemen masalah
proaktif, maupun masalah dari supplier/kontraktor. Masalah dari
supplier/kontraktor langsung dimasukan ke sistem manajemen masalah oleh
tim IT Helpdesk.
8. Melakukan penanganan masalah
Masalah yang masuk ke sistem manajemen masalah dikategorisasi dan diberi
prioritas penanganan. Masalah selanjutnya dilakukan investigasi dan diagnosa
serta mencari tahu apakah masalah yang muncul sudah pernah ada pada
known-error database. Jika belum ada pada known-error database dan
ditemukan solusi jangka pendek/workaround maka dicatat pada known-error
database. Apabila diperlukan solusi jangka panjang yang memerlukan
perubahan maka perubahan di sistem maka perubahan dikerjakan oleh 2nd
level atau vendor (jika perlu diteruskan ke vendor) dengan status “dalam
proses” sampai solusi jangka panjang diterapkan. Setelah ada solusi jangka
panjang maka masalah kemudian diubah statusnya menjadi “selesai”.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
101
Universitas Indonesia
Gambar 4.14 Proses manajemen masalah
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
102
Universitas Indonesia
Gambar 4.15 BPMN manajemen masalah
9. Mengelola known-error database
TI membuat suatu known-error database. Semua masalah atau error yang
sudah diketahui solusi jangka pendeknya dicatat pada basisdata ini. Solusi
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
103
Universitas Indonesia
jangka pendek yang ada dapat diperbaharui oleh tim IT Helpdesk yang sedang
melakukan penanganan jika solusi lain yang lebih efektif dan efisien.
10. Meninjau efektivitas penanganan
Dilakukan peninjauan efektivitas penangan oleh tim IT Helpdesk atas
Masalah dengan keterangan sebagai masalah major. Peninjauan juga
dilakukan untuk event, dan insiden yang dianggap signifikan. Tim IT
Helpdesk juga melakukan peninjauan mengenai event dan masalah yang tidak
tertangani dengan efektif dan efisien dengan data secara otomatis dari catatan
sistem.
11. Monitor/Mengawasi
IT Development Head melakukan pengawasan kinerja IT Helpdesk dengan
menggunakan kriteria pengukuran performa berupa:
a. Survei ke dalam organisasi:
o Efficacy: Apakah dukungan layanan TI memuaskan?
o Effectiveness: Apakah pemenuhan permintaan dukungan layanan TI
membuat operasional bisnis tidak terganggu oleh hal-hal terkait TI?
b. Laporan dari sistem:
o Efficiency: Jumlah permintaan dukungan layanan TI yang terpenuhi.
o Efficiency: Penggunaan sumber daya IT Helpdesk digunakan dalam
memberikan pemenuhan permintaan dukungan layanan TI dari
pengguna.
12. Mengambil tindakan
Manajemen mengambil tindakan untuk melakukan perbaikan/meningkatan
operasi layanan IT Helpdesk berdasarkan hasil pengawasan kinerja IT
Helpdesk.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
104
Universitas Indonesia
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
Manajemen masalah proaktif
Menerima umpan balik dari sistem lain
Manajemen masalah proaktif
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
105
Universitas Indonesia
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
Menerima umpan balik dari sistem lain
Belum ada, perlu ditambahkan modifikasi
Manajemen event
Mentransfer informasi event ke sistem lain
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
Menerima umpan balik dari sistem lain
Belum ada, perlu ditambahkan modifikasi
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
Manajemen masalah proaktif
Memberikan laporan trend event / insiden / masalah
Ada
Manajemen masalah proaktif
Menerima inisiatif dari tim IT Helpdesk
Ada
Manajemen masalah proaktif
Menerima umpan balik dari sistem lain
Belum ada, perlu ditambahkan modifikasi
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
106
Universitas Indonesia
Sistem Fitur Komentar Manajemen masalah proaktif
Mentransfer informasi event ke sistem lain
Belum ada, perlu ditambahkan modifikasi
Manajemen masalah
Menerima umpan balik dari sistem lain
Ada
Manajemen masalah
Mentransfer informasi event ke sistem lain
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
Known-Error Database
Mencatat error dan resolusi yang ada Ada
Known-Error Database
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
107
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
108
Universitas Indonesia
4.12.2 Draft SOP Manajemen Insiden IT Helpdesk
1. Tujuan
Standard Operating Procedure (SOP) ini dimaksudkan untuk memberikan
panduan pada proses penanganan insiden di IT Helpdesk agar tercipta tertib
administrasi dalam pelaksanaan prosedur penanganan insiden. Dengan
berlakunya SOP ini, maka diharapkan dapat menciptakan kontrol yang baik
pada penanganan insiden pada bagian IT Helpdesk.
2. Ruang lingkup
a. Prosedur ini berlaku pada bagian IT Helpdesk.
b. Prosedur ini meliputi penanganan insiden pada IT Helpdesk.
3. Definisi
a. Insiden: Permintaan dari user baik berupa permintaan informasi, laporan
terkait permasalahan TI, dan permintaan dalam bentuk formulir
elektronik yang muncul.
4. Dasar Kebijakan
a. Permintaan layanan TI dikerjakan oleh tim dari Divisi IT sebagai pemilik
dari layanan TI terkait dengan infrastruktur jaringan, sistem server,
perubahan aplikasi, dan manajemen akses.
5. Dokumen
a. Tidak ada
6. Diagram Prosedur Manajemen insiden IT Helpdesk
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
109
Universitas Indonesia
Gambar 4.17 SOP Manajemen Insiden IT Helpdesk (1)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
110
Universitas Indonesia
Gambar 4.18 SOP Manajemen Insiden IT Helpdesk (2)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
111
Universitas Indonesia
Gambar 4.19 SOP Manajemen Insiden IT Helpdesk (3)
4.12.3 Draft SOP Manajemen Masalah Proaktif IT Helpdesk
1. Tujuan
Standard Operating Procedure (SOP) ini dimaksudkan untuk memberikan
panduan pada proses manajemen masalah proaktif di IT Helpdesk agar
menjaga budaya continous improvement pada Toyota Astra Finance. Dengan
berlakunya SOP ini, maka diharapkan dapat menciptakan inisatif-inisatif
perbaikan pada penanganan insiden di bagian IT Helpdesk.
2. Ruang lingkup
a. Prosedur ini berlaku pada bagian IT Helpdesk.
b. Prosedur ini meliputi manajemen masalah proaktif pada IT Helpdesk.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
112
Universitas Indonesia
3. Definisi
Tidak ada
4. Dasar Kebijakan
a. Budaya continous improvement (Kaizen) di perusahaan merupakan hal
yang terus digalakan melalui Corporate Planning and Improvement
Department ke semua departement dan cabang. Begitu juga dengan
pengelolaan IT Helpdesk, permintaan layanan TI dikerjakan oleh tim dari
Divisi IT sebagai pemilik dari layanan TI harus terus mengalami
peningkatan dan perbaikan.
5. Dokumen
a. Tidak ada
6. Diagram Prosedur Manajemen masalah proaktif IT Helpdesk
Gambar 4.20 SOP Manajemen Masalah Proaktif
4.12.4 Draft SOP Manajemen Masalah IT Helpdesk
1. Tujuan
Standard Operating Procedure (SOP) ini dimaksudkan untuk memberikan
panduan pada proses penanganan masalah di IT Helpdesk agar tercipta tertib
administrasi dalam pelaksanaan prosedur penanganan masalah. Dengan
berlakunya SOP ini, maka diharapkan dapat menciptakan kontrol yang baik
pada penanganan masalah pada bagian IT Helpdesk.
2. Ruang lingkup
a. Prosedur ini berlaku pada bagian IT Helpdesk.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
113
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
114
Universitas Indonesia
Gambar 4.21 SOP Manajemen Masalah IT Helpdesk (1)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
115
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
116
Universitas Indonesia
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).
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
117
Universitas Indonesia
Aktivitas yang diukur
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.
Pemenuhan Permintaan
Jumlah backlog saat ini.
Pemenuhan Permintaan
Waktu rata-rata penyelesaian penanganan tiap jenis permintaan layanan.
Pemenuhan Permintaan
Jumlah dan persentase permintaan layanan yang selesai dalam batas waktu yang disepakati.
Pemenuhan Permintaan
Rata-rata biaya per permintaan layanan.
Pemenuhan Permintaan
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
118
Universitas Indonesia
Aktivitas yang diukur
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
119
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
120 Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
121
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
122
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
123
Universitas Indonesia
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.
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
124 Universitas Indonesia
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,
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
125
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
126
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
127
Universitas Indonesia
Lampiran 2 Transkrip Wawancara Dengan agen IT Helpdesk
Narasumber : DRO
Jabatan Narasumber : IT Helpdesk Support
PT Toyota Astra Financial Service
Tanggal Wawancara : 15 November 2014
Tempat Wawancara : Kantor Cabang Kelapa Gading
PT Toyota Astra Financial Service
Id 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,
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
128
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
129
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
130
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
131
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
132
Universitas Indonesia
Lampiran 3 Transkrip Wawancara Dengan IT Analyst / 2nd Level Support
Narasumber : JSE
Jabatan Narasumber : IT Developer / Analyst
PT Toyota Astra Financial Service
Tanggal Wawancara : 19 November 2014
Tempat Wawancara : Head Office PT Toyota Astra Financial Service
Id 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?
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
133
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
134
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
135
Universitas Indonesia
Lampiran 4 Transkrip Wawancara Dengan Supervisor IT Helpdesk
Narasumber : GAL
Jabatan Narasumber : IT Developer / Analyst
PT Toyota Astra Financial Service
Tanggal Wawancara : 19 November 2014
Tempat Wawancara : Head Office PT Toyota Astra Financial Service
Id 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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
136
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
137
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
138
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
139
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
140
Universitas Indonesia
Lampiran 5 Transkrip Wawancara dengan IT Development Head
Narasumber : TSU
Jabatan Narasumber : IT Development Department Head
PT Toyota Astra Financial Service
Tanggal Wawancara : 26 November 2014
Tempat Wawancara : Head Office PT Toyota Astra Financial Service
Id 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?
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
141
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
142
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
143
Universitas Indonesia
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?
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
144
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
145
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
146
Universitas Indonesia
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
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
147
Universitas Indonesia
(Lanjutan)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
148
Universitas Indonesia
(Lanjutan)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
149
Universitas Indonesia
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:
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
150
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
151
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
152
Universitas Indonesia
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)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
153
Universitas Indonesia
Lampiran 9 Contoh SOP Toyota Astra Finance
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
154
Universitas Indonesia
(Lanjutan)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
155
Universitas Indonesia
(Lanjutan)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015
156
Universitas Indonesia
(Lanjutan)
Manajemen Operasi..., Bayu Kusuma Wijaya, FASILKOM UI, 2015