Dukungan Teknis KPI Miran

"" Apakah kamu memiliki teman dengan wajah merah, tiga mata dan kalung tengkorak? "Dia bertanya.
"Siapa yang menari di antara api unggun?" Hah? Masih jangkung seperti itu? Dan melambaikan kurva pedang?
"Mungkin ada," katanya dengan sopan, "aku tidak bisa mengerti siapa yang kamu bicarakan." Anda tahu, fitur yang sangat umum. Siapa pun bisa. "

Victor Pelevin, "Chapaev and the Void"

Halo, Habr! Nama saya Alexander Solovyov, saya memimpin dukungan teknis di pusat data Miran.

Beberapa waktu lalu saya ambil bagian dalam pertemuan menarik yang didedikasikan untuk dukungan teknis KPI. Secara umum, itu adalah acara yang berguna dalam hal berbagi pengalaman. Namun demikian, tetap ada endapan "ketidaklengkapan". Alasannya adalah, pertama-tama, bahwa peserta acara berbagi pengalaman mereka, dan baik saya maupun mereka tidak menyimpulkan generalisasi atau bahkan hasil.

Acara ini diselenggarakan oleh komunitas dukungan teknis SUPNET yang, dilihat dari publikasi terbaru di halaman resmi mereka, tertanggal September 2018, “go to nirvana”.

Karena itu, saya mengambil kebebasan dalam artikel ini untuk membagikan praktik terbaik saya dan mencoba merangkum apa yang dikatakan berdasarkan pengalaman saya.

Jadi, jika kita menganggap dukungan teknis kami sebagai "kotak hitam", maka kita dapat mengatakan ini: kotak ini melakukan fungsi yang berguna, mengubah permintaan dukungan informal menjadi aplikasi lengkap yang diformalkan. Kotak memiliki kinerja tertentu, pesanan selesai sesuai dengan tingkat kualitas yang diberikan, dan pengoperasian kotak itu cukup mahal bagi kami.

Secara umum, ini semua yang perlu Anda ketahui tentang dukungan teknis KPI, tetapi jika Anda tertarik dengan perinciannya, selamat datang di ... Semua orang diundang ke sana kepada siapa saya berjanji untuk memberi tahu Anda tentang indeks tingkat pengetahuan.

Jadi, KPI dibagi menjadi tiga kelompok:

• Indikator kinerja - mencerminkan efektivitas biaya dalam mencapai hasil tertentu, misalnya, gaji rata-rata seorang insinyur.
• Indikator kinerja - pada kenyataannya, "bilah kemajuan", misalnya, persentase pelanggaran waktu reaksi terhadap aplikasi untuk periode pelaporan.
• Indikator kinerja - indikator signifikan kegiatan operasional, misalnya, jumlah permintaan dukungan teknis untuk periode pelaporan.

Indikator kinerja

Saya akan mulai dengan efisiensi.

1. Gaji rata-rata seorang insinyur dukungan teknis;
   
2. FRT - waktu rata-rata dari respons pertama terhadap aplikasi;
   
3. ART - waktu tunggu rata-rata;
   
4. MTTR adalah waktu perbaikan rata-rata.
   

Gaji rata-rata seorang insinyur

Karena upah kami adalah upah per satuan, arti dari indikator ini adalah untuk menunjukkan manajemen dalam hal apa, dalam kata-kata jenderal kami, adalah dana penggajian dari teknisi pendukung teknis. Setelah mengoperasikan "menyeimbangkan" dana penggajian melalui motivasi non-finansial, indikatornya menjadi kurang relevan, tetapi secara umum masih dipertimbangkan. Saya akan menambahkan bahwa nilai indikator dihitung untuk setiap jalur dukungan teknis, yang memungkinkan saya untuk menjaga jari saya pada denyut nadi dan, jika perlu, menyesuaikan tingkat upah pekerjaan sesuai untuk bulan berikutnya.

FRT / ART

Kedua indikator “tumbuh” dari Perjanjian Tingkat Layanan (SLA). Mengikuti SLA, jika FRT / ART terlampaui, klien memiliki hak untuk menghitung ulang jumlah pembayaran untuk layanan terdegradasi. Menurut pendapat saya, indeks ini serupa artinya dengan suhu rata-rata di rumah sakit). Secara praktis, manfaat dari indeks tidak banyak, satu-satunya hal adalah bahwa mereka memungkinkan manajemen perusahaan untuk memahami bahwa indikator yang dinyatakan dalam SLA sudah hampir terpenuhi. Jauh lebih berguna adalah persentase pelanggaran terhadap respons / waktu eksekusi aplikasi, indikator ini memungkinkan Anda untuk dengan cepat dan jelas mengevaluasi dinamika pemrosesan aplikasi dengan dukungan teknis.

MTTR

Indikator ini banyak dikenal di kalangan sempit (alias IRT - insiden Resolution Time), waktu perbaikan rata-rata, dalam kasus kami, penggunaan indikator ini kecil karena layanan yang disediakan oleh perusahaan kami sangat bervariasi. Mungkin di masa depan kami akan mempertimbangkan MTTR secara terpisah untuk setiap produk. Namun, karena ini adalah indikator yang sangat terkenal, kami mempertimbangkannya.

Indikator kinerja

Mari beralih ke kinerja.

1. EKi - indeks pengetahuan karyawan;
   
2. CSi - indeks kepuasan pelanggan dengan layanan;
   
3. FRTR - persentase pelanggaran waktu tanggapan terhadap pengobatan;
   
4. ARTR - persentase pelanggaran waktu tunggu .
   

Csi

Indeks Kepuasan Pelanggan adalah umpan balik pelanggan digital, yaitu pendapat pelanggan tentang kualitas layanan yang diterima. Perhitungan indeks dibuat semata-mata berdasarkan penilaian subyektif klien yang kami terima setelah menyelesaikan setiap aplikasi. CSi adalah indikator yang paling penting, yang paling mudah dipahami dan relevan bagi semua orang. Berbeda dengan indikator sebelumnya, metode perhitungan yang jelas, saya akan memberitahu secara rinci tentang metode perhitungan CSi kami.

Nilai indeks tergantung pada tiga parameter:

1. Waktu reaksi terhadap sirkulasi, t ₁ ;
   
2. Waktu keputusan aplikasi, t ₂ ;
   
3. Kualitas keputusan aplikasi, q.

Rumus untuk menghitung CSi adalah sebagai berikut:

$$

$$CSi = \ frac {3} {({t_1} ^ {t_1} + {t_2} ^ {t_2} + {q ^ q})}$$

Kisaran nilai parameter yang mungkin diberikan dalam tabel.

Nilai-nilai yang dihasilkan ditafsirkan menurut tabel berikut.

Eki

Indeks tingkat pengetahuan karyawan menunjukkan apakah pengetahuan karyawan sesuai dengan tingkat minimum yang dapat diterima yang dapat diterima oleh insinyur dukungan teknis. Memungkinkan Anda untuk berhenti berbicara tentang ketidaklengkapan insinyur untuk menunjukkan kepada manajemen perusahaan betapa kompeten dan siap bekerjanya teknisi pendukung teknis. Indeks ini tidak terlalu cocok untuk insinyur, tetapi bagus untuk manajemen dan spesialis PR kami).

Perhitungan indeks didasarkan pada data objektif yang diperoleh sebagai hasil dari pemeriksaan rutin pelatihan pengetahuan insinyur, yang dilakukan dengan metode pemodelan simulasi, yaitu solusi situasi khas yang disebut kasus pengguna. Siapa peduli, saya berbicara lebih banyak tentang manajemen pengetahuan dalam dukungan teknis di KnowledgeConf 2019 .
Di perusahaan kami, EKi dihitung sebagai rasio kasus pengguna yang berhasil diselesaikan dengan jumlah total kasus pengguna untuk periode tersebut.

$$

$$EKi = \ frac {U_w} {U_a}$$

dimana
U _w - jumlah kasus pengguna yang berhasil diselesaikan oleh insinyur untuk periode pelaporan;
U _a - jumlah total kasus pengguna yang diputuskan oleh insinyur untuk periode pelaporan.

Nilai-nilai yang dihasilkan ditafsirkan menurut tabel berikut.

Tingkat 0,85 dan 0,95 diperoleh oleh kami secara eksperimental ahli, sebagai hasil dari lebih dari dua tahun pengalaman dalam mengelola pengetahuan insinyur dukungan teknis .

Persentase pelanggaran waktu reaksi / runtime

Indeks persentase pelanggaran waktu reaksi / runtime yang saya sebutkan di atas. Bahkan, mereka menunjukkan seberapa sering dukungan teknis melanggar SLA dalam hal waktu reaksi dan waktu tunggu.

Indikator kinerja

Akhirnya, indikator produksi:

• jumlah aplikasi yang diproses oleh dukungan teknis untuk periode pelaporan:
  
  • dimana panggilan;
  • dari mana pesan dari sistem pemantauan;
  • yang ditolak;
  • di antaranya adalah klien;
• jumlah aplikasi yang terkait dengan pengoperasian produk dalam periode pelaporan:
  
  • di antaranya adalah insiden;
  • di antaranya adalah banding;
  • Total waktu "penolakan layanan" untuk semua pelanggan produk untuk periode pelaporan.

Ada aturan yang menentukan rasio KPI untuk mengevaluasi kinerja secara keseluruhan. Menurut aturan ini, indikator harus didistribusikan dalam proporsi 10/80/10 = indikator kinerja / indikator produksi / indikator kinerja.

Untuk alasan ini, ada banyak indikator produksi dan saya hanya akan fokus pada yang paling penting dari sudut pandang saya.

Jumlah panggilan dukungan teknis

Tentu saja, jumlah panggilan untuk dukungan teknis merupakan indikator penting yang harus diperhitungkan baik untuk organisasi kerja maupun untuk mencerminkan kinerja dukungan teknis. Datang ke semua orang)

Karena banding banding berbeda, masuk akal untuk membedakan aliran umum banding dengan totalitas sumber banding dan "esensi" banding. Dalam kasus kami, ini adalah sistem pemantauan, panggilan telepon masuk, panggilan salah, dan akhirnya panggilan klien.

Jumlah aplikasi yang terkait dengan pengoperasian produk

Di sisi lain, masuk akal untuk mengintegrasikan banding terkait setiap produk (layanan) kami ke dalam kelompok dengan nama yang sama. Misalnya, dalam kasus kami, disarankan untuk mengelompokkan panggilan yang terkait dengan layanan penyewaan daya komputasi dan layanan yang terkait dengan penempatan peralatan di pusat data dalam grup yang berbeda. Ini praktik yang baik ketika panggilan dalam suatu kelompok dibagi dengan jumlah total panggilan, jumlah "penolakan layanan" dan total waktu henti untuk layanan yang termasuk dalam produk.

Kesimpulan

Ketika sudah terlambat apa yang harus diubah secara signifikan Seperti biasa, setelah menulis artikel saya mencari KPI untuk dukungan teknis, saya google beberapa artikel menarik, berikut adalah beberapa di antaranya:

• Apa KPI Helpdesk IT yang Harus Anda Lacak?
• 8 Metrik dan KPI desk help kunci

Saya memahami apa yang saya baca dan tidak mengubah apa pun di artikel saya, karena menurut saya lebih jujur ​​dan lebih alami. Jika diinginkan, pembaca dapat memeriksa seberapa banyak dukungan teknis kami "dalam tren".

Mungkin hal utama yang saya pelajari dari apa yang saya baca adalah bahwa dalam dukungan teknis kami, kami harus memiliki dua indeks tambahan:

1. FCR - jumlah aplikasi yang diselesaikan dalam aplikasi pertama untuk dukungan;
2. FTFR - persentase aplikasi yang diselesaikan sebagai bagian dari aplikasi pertama untuk dukungan.