Geekly articles weekly

Dukungan teknis Miran: cara kerjanya

Api tempat Anda membakar harus dijaga.
V.O. Pelevin, “Generasi P”



Halo, Habr! Nama saya Alexander Soloviev, saya adalah kepala dukungan teknis untuk pusat data Miran.

Katakan padaku, sudahkah kamu mencoba menulis buku teks? Saya tidak. Namun demikian, teks di bawah ini adalah semacam panduan pelatihan untuk mengatur dukungan teknis. Sebagai bagian dari artikel ini, saya ingin memberi tahu Anda apa dukungan teknis dari pusat data Miran: "roda gigi" seperti apa dan mengapa mereka berputar dengan cara ini, dan bukan sebaliknya.


Demi kenyamanan pembaca, saya akan membagi artikel ini menjadi beberapa bagian semantik.

  1. Pada bagian pertama, kita akan berbicara tentang elemen dasar kerja TP - staf, siklus hidup aplikasi, prioritas.
  2. Pada bagian kedua , kami akan membahas masalah mempertahankan pengetahuan insinyur dukungan teknis pada tingkat tertentu.
  3. Pada bagian ketiga dan terakhir, kita akan berbicara tentang bagaimana membuat semua hal di atas berhasil.

Saya akan berbicara tentang motivasi, khususnya, non-finansial, serta memberikan beberapa tips untuk mengatur penghargaan dan hukuman perusahaan.

Dasar Dukungan Teknis


Untuk mengatur pekerjaan dukungan teknis, Anda perlu menjawab beberapa pertanyaan sederhana:

  1. Ini memerlukan dukungan untuk satu produk (layanan) atau apakah itu tentang dukungan multi-produk, yaitu mendukung beberapa produk yang sama sekali berbeda?
  2. SLA apa yang diperlukan untuk panggilan dukungan teknis?
  3. Apakah dukungan setiap saat dibutuhkan?


Pertama


Dukungan monoproduk memerlukan jumlah spesialis minimum. Misalnya, jika Anda mengharapkan sekitar sepuluh aplikasi per shift, Anda dapat mencoba mengalihkan dukungan ke insinyur khusus.
Dukungan multi-produk mensyaratkan pemilihan spesialis produk, atau pemisahan lalu lintas panggilan dengan kompleksitas, yang dinyatakan dalam organisasi beberapa jalur dukungan.
Kami mengambil jalur membagi insinyur sesuai dengan pengetahuan dan kompetensi mereka menjadi tiga komponen: jalur dukungan teknis pertama, tambahan, dan kedua.

Kedua


Semakin keras SLA, semakin banyak sumber daya yang perusahaan harus patuhi. Ini adalah berbagai sumber daya: insinyur yang berkualifikasi, sistem informasi, peralatan, dokumen peraturan, dll. Pertimbangkan masalah staf. Untuk memenuhi persyaratan SLA, staf harus proporsional dengan jumlah rata-rata panggilan dukungan teknis, dengan mempertimbangkan waktu dan standar kualitas.

Berdasarkan hal di atas, staf teknisi kami adalah sebagai berikut:
• baris pertama - 10 orang;
• saluran tambahan - 4 orang;
• baris kedua - 5 orang.

Ketiga


Dukungan teknis sepanjang waktu adalah layanan yang mahal. Kinerja berkualitas tinggi dari layanan ini dalam mode 24x7x365 akan membutuhkan setidaknya 5 insinyur, dan ini dalam kasus yang paling sederhana, mis. dalam hal dukungan produk tunggal. Jika Anda perlu mengatur dukungan sepanjang waktu, jangan ragu untuk melipatgandakan biaya dengan 5. Namun, pertama-tama, pikirkan apakah Anda memerlukannya (dapat Anda lakukan tanpa portal swalayan, dll.). Jika Anda masih membutuhkannya, apakah mungkin untuk melakukan outsourcing.



Apa yang dilakukan orang-orang ini?


Tugas insinyur lini pertama adalah memproses banding klien dengan cepat dan efisien. Memproses berarti mengklasifikasikan dan mengirim pekerjaan dengan benar.
Setelah diproses, insinyur dari baris pertama akan menyelesaikan aplikasi sendiri jika itu dari bagian "lakukan dengan cepat, di sini dan sekarang", atau transfer aplikasi ke baris lain jika itu "lama bermain" atau jika itu adalah "kerusakan".
Tugas insinyur lini tambahan adalah bekerja dengan aplikasi yang membutuhkan waktu lebih dari satu hari untuk diselesaikan.
Tugas insinyur lini kedua adalah memecahkan masalah secepat mungkin dan menyelesaikan aplikasi kompleks "di sini dan sekarang".

Mode Insinyur


Baris pertama : jadwal - 2/2, shift 12 jam dari pukul 08:00 dan 20:00.
Baris tambahan : jadwal - lima hari, shift 8 jam dari pukul 08:00 dan dari pukul 12:00.
Baris kedua : jadwal - 2/2, shift 12 jam dari pukul 08:00 dan 20:00.

Jadwal shift insinyur dipertahankan melalui Kalender Google.



Siklus hidup dan status aplikasi dalam TP


Cara termudah untuk melacak siklus hidup aplikasi sesuai dengan skema ini:


Saya akan menjelaskan masing-masing poin secara terpisah.

  • Status baru diperoleh oleh aplikasi apa pun yang diterima dari sumber eksternal. Tugas insinyur dari garis pertama adalah untuk awalnya memproses aplikasi yang diterima dan mentransfernya ke kontraktor.
  • Status terbuka ditetapkan untuk aplikasi ketika spesialis sibuk dengan keputusan.
  • Jika aplikasi telah diidentifikasi sebagai spam, ia memperoleh status yang dihapus .
  • Jika aplikasi ini bukan spam, tetapi tidak mengandung daya tarik penting untuk dukungan teknis, itu ditetapkan statusnya ditolak .
  • Status yang diselesaikan ditetapkan ke aplikasi setelah menyelesaikan masalah / masalah sesuai dengan pelaku.
  • Status terhenti berarti bahwa pekerjaan pada aplikasi ditangguhkan sementara atas inisiatif klien atau dalam perjanjian dengannya.
  • Status ditutup ditetapkan setelah klien menganggap bahwa tugasnya telah berhasil diselesaikan.


Pengetikan aplikasi


Jenis aplikasi adalah kriteria paling penting. Ini menentukan tingkat reaksi dan waktu untuk menyelesaikan masalah yang ditunjukkan dalam tiket. Di Miran, menurut ITIL, permintaan dibagi menjadi beberapa tipe berikut. Saya memberi mereka dalam urutan kepentingan:

Insiden
Insiden termasuk kerusakan peralatan dan kegagalan fungsi, serta peristiwa lainnya yang menyebabkan penurunan kualitas layanan yang signifikan. Aplikasi jenis ini dijalankan berdasarkan prioritas dan diutamakan daripada jenis aplikasi lainnya. Hanya insiden yang dapat diutamakan daripada diproses.

Contoh insiden: tidak tersedianya layanan, kegagalan perangkat keras.

RFS - Permintaan Layanan
Pelanggan memiliki kebutuhan akan layanan sebagai bagian dari layanan yang disediakan. Permintaan tidak terkait dengan kegagalan atau kegagalan dalam infrastruktur TI. Ini dilakukan segera dalam antrian umum dengan tidak adanya aplikasi prioritas.

Contoh: permintaan untuk me-restart server.

RFC - Ubah Permintaan
Permintaan untuk perubahan dalam komposisi dan / atau ruang lingkup layanan yang diberikan kepada klien. Waktu pemrosesan ditentukan oleh manajemen perusahaan secara individual sesuai dengan klien.

Contoh: permintaan untuk mengganti peralatan.

RFI - Permintaan Informasi
Informasi tentang layanan diminta, termasuk laporan tentang volume konsumsi energi, laporan layanan, dll. Ini dilakukan segera dalam antrian umum dengan tidak adanya aplikasi prioritas.

Prioritas aplikasi, yang mempengaruhi kecepatan reaksi dan keputusan, dihitung berdasarkan informasi yang diterima dari klien, dengan mempertimbangkan sejumlah aturan dan pesanan internal. Ada dua prioritas: awal dan akhir. Prioritas awal diatur sesuai dengan klien dan menentukan kecepatan pemrosesan insiden. Prioritas akhir ditetapkan oleh insinyur setelah menyelesaikan pekerjaan dan mencerminkan tingkat degradasi layanan yang sebenarnya. Seringkali prioritas ini tidak sama.

Prioritas dialokasikan sebagai berikut:

  • berfungsinya segmen jaringan rusak (pusat komunikasi tidak tersedia, saklar dasar rusak) - 40;
  • degradasi yang signifikan dari beberapa layanan yang diberikan kepada klien - 30;
  • degradasi yang signifikan dari salah satu layanan yang diberikan kepada klien - 20;
  • degradasi layanan, yang tidak memiliki dampak signifikan pada sifatnya - 10;
  • tidak berpengaruh pada layanan pelanggan - 0.

Saya pikir ini dapat menyelesaikan analisis teorinya dengan lancar. Di belakang layar akan ada waktu respons untuk insiden dan permintaan, tingkat eskalasi, motivasi keuangan dan informasi lainnya, kurang lebih standar untuk perusahaan lain. Mari kita beralih ke hal-hal yang lebih menarik.

Mempertahankan tingkat pengetahuan yang dibutuhkan


Dalam pekerjaan layanan dukungan teknis, kami berusaha untuk mengatur segala sesuatu yang diatur, untuk transparan kepada klien, dan juga untuk memformalkan dan mendigitalkan informasi yang mungkin berguna dan dapat diterapkan di masa depan. Umpan balik dari pelanggan, tingkat pengetahuan karyawan kami, prestasi dan wajah mereka - semua ini dengan cermat didigitalkan, dianalisis, dan selanjutnya memengaruhi keputusan manajemen.

Selama beberapa hari libur, seorang insinyur dukungan teknis dapat mengubah beberapa peraturan, yang baru "pengantar" akan muncul, yang berarti bahwa pada awal shift itu perlu untuk memeriksa relevansi pengetahuan insinyur. Ini dilakukan dengan bantuan teknologi pemodelan situasional, dengan pelatihan untuk menyelesaikan situasi di mana pengetahuan yang ditentukan dalam permintaan. Kami menyebut satu situasi sebagai kasus. Pada awal shift, insinyur menerima sebagian dari beberapa kasus pengguna. Pendekatan ini memungkinkan para insinyur untuk mempertahankan pengetahuan yang diperlukan dalam pikiran mereka dan terus memperbaruinya. Akibatnya, kualitas kerja meningkat. Untuk mengurangi stres, batas waktu untuk menyelesaikan kasus pengguna ditetapkan pada akhir shift, meskipun sebenarnya cukup sepuluh menit untuk spesialis.

Apa sebenarnya yang dimaksud dengan case pengguna tipikal?

Total ada 4 blok semantik:

  1. Blok informasi
    Ini berisi informasi berguna yang perlu dipelajari.
  2. Bundel bundel
    Blok ini memungkinkan Anda untuk mengaitkan informasi baru dengan "pengangkutan" informasi ini dalam memori manusia.
  3. Opsi jawaban
    Bahkan, ini adalah "transportasi" informasi dalam memori.
  4. Tautan bukti
    Tautan ke sumber tepercaya tempat Anda dapat mempelajari informasi ini.



Inilah yang terlihat seperti kasus pengguna standar pada contoh materi historis

Semua blok Usercase terkait dalam makna dan tema. Idealnya, blok informasi harus berisi petunjuk tentang opsi jawaban, dan untuk klarifikasi, Anda perlu membuka prooflink dan mempelajari secara detail pertanyaan yang sedang diperiksa di sana.

Memperkenalkan praktik ini, saya menemukan satu momen yang tidak menyenangkan: tidak ada satu pun alat lengkap di pasar yang akan memungkinkan Anda untuk menyimpan basis pengetahuan, "dengan cerdas" mendistribusikan kasus pengguna oleh karyawan dan memeriksa jawaban mereka.

Saat ini kami menggunakan banyak alat.

  • Request Tracker (RT) - mendefinisikan logika interaksi sistem.
  • Kalender Google oleh API "memberikan" daftar karyawan dan jumlah kasus pengguna untuk masing-masing.
  • Google Spreadsheets memberikan informasi untuk pembentukan case pengguna.

Faktanya, sistem bekerja sebagai berikut:

  1. Daftar karyawan yang terlibat dalam pelatihan pengetahuan dibentuk.
  2. Untuk setiap karyawan, topik kasus pengguna ditentukan.
  3. Kasing pengguna dibuat untuk setiap topik dan ditransfer ke karyawan.
  4. Selama hari kerja, insinyur harus menyelesaikan semua kasus pengguna.
  5. Jawabannya diperiksa, dan hasil verifikasi setiap kasus pengguna disimpan dalam sistem.

Seorang insinyur yang baik menyelesaikan satu kasus pengguna dalam waktu sekitar satu menit. Untuk menipu dan "menghitung" cukup bermasalah, kami menangani sistem anti-cheat kami sendiri.

Ingat: jangan pernah mencoba mengelola tingkat pengetahuan karyawan di departemen-departemen tersebut di mana Anda tidak mengendalikan motivasi.

Senapan, burung beo dan motivasi


Saya berbicara dengan cukup rinci tentang cara kerja layanan dukungan teknis. Masih memahami titik penting lainnya: mengapa itu bahkan berhasil? :)

Semuanya bertumpu pada dua pilar. Pilar-pilar ini adalah motivasi non-finansial dan finansial.

Gangster terkenal Al Capone berkata: "Dengan kata-kata yang baik dan pistol Anda dapat mencapai lebih dari sekedar kata yang baik." Sangat disesalkan, dalam metafora ini motivasi finansial adalah kata yang baik, dan nonkeuangan sudah menjadi senjata "tua yang baik".

Motivasi non-finansial



Tiga pilar motivasi non-finansial: kelaparan, dingin dan obyektivitas penilaian, bukti akrual, kemudahan administrasi

Setiap orang bereaksi sangat negatif terhadap denda yang dinyatakan dalam uang ... tetapi untungnya, mereka lebih mudah khawatir tentang denda dalam "burung beo". Sementara itu, burung beo, jika Anda bisa memasaknya, sangat, sangat signifikan memotivasi karyawan.

Kami telah memilih sebagai kualitas. burung beo mati, tetapi secara teoritis Anda dapat memilih sesuatu yang lain. Waktu senggang adalah baik karena kami merasakannya oleh semua karyawan, itu dibutuhkan untuk tujuan yang dimaksudkan dan tidak perlu menjelaskan kepada bawahan apa itu dan untuk apa. Pertama-tama, ketika memilih unit akun, seseorang harus melanjutkan dari fakta bahwa itu seharusnya tidak menjadi "kuda bulat dalam ruang hampa". Unit akuntansi harus berwujud bagi karyawan.

Dalam kerangka motivasi non-finansial, karyawan dihilangkan bukan karena uang, tetapi waktu istirahat dan, karenanya, kesempatan untuk menggunakan manfaat dari motivasi non-finansial. Ini tidak menyenangkan, tetapi tidak seperti denda: ada insentif untuk tumbuh, dan loyalitas seseorang kepada perusahaan tidak menderita. "Feats" didorong oleh waktu istirahat. Seorang karyawan dapat menggunakan hari libur untuk tujuan yang dimaksudkan: misalnya, berbaring di rumah, tetapi ini tidak begitu menarik. Lebih menarik untuk pergi ke kasino dengan blackjack dan mademoiselle untuk meluangkan waktu untuk acara-acara yang penting bagi diri Anda atau perusahaan Anda, misalnya: layanan medis di luar VHI, akhirnya mendapatkan sertifikat profesional, paket kebugaran, atau paket wisata.

Satu-satunya waktu istirahat dikurangi dibandingkan dengan uang adalah bahwa setiap kasus penggunaan, baik secara langsung atau dalam hal moneter, perlu diverifikasi secara terpisah oleh pihak berwenang, yang tidak selalu nyaman. Harga waktu istirahat dari kami adalah 3000 rubel, Anda mungkin memiliki lebih atau kurang. Hal utama adalah kenyamanan bersama dari menggunakan unit motivasi non-finansial.

Biarkan saya memberi Anda contoh hidup ketika karya tertentu diberikan dengan cara non-finansial.

Menyusun dokumen yang bagus dengan case pengguna untuk basis pengetahuan bukanlah tugas sebagai proses. Setiap bulan sesuatu yang baru muncul: pelanggan, peralatan, perangkat lunak. Semua ini, untuk alasan yang telah disebutkan di atas, membutuhkan perhatian dan dokumentasi yang cermat.

Jika pada awalnya saya bekerja pada kompilasi dokumen-dokumen ini sendiri, sekarang sistem pengisian basis pengetahuan bekerja hampir secara mandiri. Tugas saya adalah membimbing karyawan ke arah yang benar, memberi mereka vektor gerakan dan melakukan kontrol keluar.

Pengalaman saya menunjukkan bahwa "harga" satu dokumen bagus yang dilengkapi dengan jumlah kasus pengguna yang cukup adalah tiga hari libur.

Seorang insinyur menerima dua hari libur untuk sebuah dokumen yang tidak memerlukan koreksi signifikan.

Seseorang menerima satu hari libur jika diperlukan banyak koreksi, dan lebih mudah membuatnya sendiri daripada menjelaskan bagaimana melakukannya dengan benar.

Kami mencoba memberikan lebih banyak waktu istirahat untuk pekerjaan ini - mulai 10 hari atau lebih. Tetapi latihan telah menunjukkan bahwa hadiah terlalu menakutkan, dan praktis tidak ada orang yang mau menerimanya. Karena itu, penting untuk tidak berlebihan dengan promosi karyawan. Ini bisa membuat Anda menyamping dengan cara yang paling tidak terduga. Lakukan eksperimen, tetapi lakukan dengan hati-hati.

Motivasi finansial


Setiap aplikasi yang dilengkapi oleh seorang insinyur TP dihargai dengan bonus. Nilai bonus berbanding lurus dengan kompleksitas aplikasi dan kualifikasi yang diperlukan untuk implementasinya. Gaji terakhir seorang insinyur ditentukan oleh jumlah bonus ini. Tentu saja, dalam hal pemenuhan aplikasi yang “bengkok”, bonusnya habis.

Nuansa lain: gaji seorang insinyur selalu dalam kisaran yang ditentukan oleh posisinya. Pada bulan paling malas, seseorang tidak akan menerima kurang dari batas bawah kisaran ini, juga tidak akan menerima lebih dari batas atas dalam kisaran paling produktif. Namun demikian, tidak ada yang akan tersinggung: semua tiang temboknya dihukum, dan pemrosesan didorong melalui motivasi non-finansial.

Untuk meringkas


Artikel itu ternyata sangat banyak, tetapi ini tidak mengejutkan: kami memeriksa kehidupan dukungan teknis Miran hampir seluruhnya, mengabaikan hanya detail paling membosankan atau umum. Namun demikian, jika saya tetap lupa untuk menulis tentang sesuatu yang menarik untuk Anda atau selama membaca, Anda memiliki pertanyaan mengenai organisasi layanan TP, saya akan dengan senang hati menjawabnya di komentar.

Materi Terkait


Source: https://habr.com/ru/post/id464137/

More articles:


All Articles