Bagaimana penyedia layanan melakukan Meja Layanannya

Halo semuanya! Nama saya Alexey Volkov. Bersama dengan kolega saya, pengembang Alexander Solovyov ( jugav ), kami melakukan layanan web internal di DataLine. Musim gugur ini, kami meluncurkan meja layanan kami untuk menggantikan BMC Remedy. Dalam sebuah pos, saya akan memberi tahu Anda mengapa kami menolak solusi yang sudah jadi dan melakukan semuanya sendiri.


Rata-rata, 450 aplikasi melewati meja layanan per hari.

Apa yang Ramuan tidak menyenangkan kami?

Saya mulai berlatih Remedy segera setelah saya masuk ke DataLine. Setelah berulang kali berupaya menyelesaikannya di bawah tugas kami, kami memutuskan untuk membuat meja layanan kami. Berikut ini adalah daftar alasan mengapa kami memutuskan untuk meninggalkan Sistem Permintaan Tindakan Perbaikan dari BMC:

Antarmuka tidak nyaman. Untuk mendaftarkan aplikasi, aktifkan dan perhatikan izinnya, kami harus membuat 100500 klik.


Halaman dengan insiden itu. Ambil setidaknya bidang untuk konten pesan yang perlu dibuka di jendela khusus.


Seluruh tab harus dibuka untuk menulis solusi atau mengalihkan insiden ke pelaksana lain.

Integrasi dengan antarmuka klien lain dan setiap perbaikan menyarankan bahkan tarian-tarian dengan rebana. Perangkat lunak berpemilik, hampir tidak ada ruang untuk bermanuver. Satu-satunya celah adalah layanan web yang tahu bagaimana berkomunikasi dengan Remedy, tetapi mereka sangat murung dan tidak stabil. Kami melakukan beberapa hal secara manual dan kikuk: Saya ingat bagaimana kami mengonfigurasi unggahan laporan tentang insiden dengan bantuan pilihan dari basis data.

Tentu saja, ada cara lain: untuk menyewa kontraktor dan memenuhi keinginan apa pun. Saat itu hanya ada satu kontraktor di pasar untuk perangkat lunak ini, dan ia tahu tentang itu. Proses produksi sedang disesuaikan, dan perbaikan akan terus dibutuhkan. Dengan pemikiran ini, label harganya menjadi tidak manusiawi dan mulai dari 5 juta.

Lisensi tidak cukup. Suatu ketika di awal DataLine, kami membeli 100 lisensi. Sejak itu, perusahaan telah tumbuh secara eksponensial. Lisensi bersaing. Semakin lama, situasi muncul ketika seorang insinyur harus menunggu lisensi untuk dirilis untuk mulai melakukan pekerjaannya. Sebenarnya, ini yang terakhir.

Memperbaiki semua tindakan insiden . Kami ingin semua yang terkait dengan dukungan teknis pelanggan tercermin di meja layanan. Pemulihan, pada kenyataannya, hanya mencatat permintaan. Semua pekerjaan nyata pada insiden itu dilakukan melalui korespondensi surat, melalui telepon, di ruang merokok - di mana saja, tetapi tidak di Remedy. Terutama jika itu adalah aplikasi yang kompleks dan melibatkan spesialis dari beberapa departemen. Mereka memecahkan masalah, tetapi tidak ada jejaknya di Remedy. Akibatnya, insiden itu didokumentasikan dalam fragmen, dan kadang-kadang tidak muncul sama sekali di Remedy. Sangat sulit untuk mengendalikan, memahami, dan menganalisis apa pun.

Meja Layanan 2.0

Fungsi pemulihan mudah diganti. Tugas utama dari meja layanan baru adalah menyeret semua aktivitas dukungan teknis ke dalam "satu jendela": kontak, korespondensi kerja, dokumen. Kami ingin mendapatkan semacam pencatatan segala sesuatu yang terjadi setelah klien mengirimkan aplikasi kepada kami untuk mendapatkan dukungan. Sepanjang jalan, kami ingin mengotomatiskan banyak hal untuk mengurangi beban pada baris pertama dukungan dan menghilangkan faktor manusia secara maksimal.

Berikut adalah fungsi terpenting yang kami terapkan di meja layanan baru:

Peristiwa transfer. Kami sering menerima aplikasi yang kompleks, yang dilakukan dalam rantai oleh spesialis dari berbagai departemen. Yang paling sederhana, aplikasi untuk akses fisik ke peralatan di pusat data. Pertama, operator menulis pass, lalu meneruskan data klien dan nomor pass ke teknisi yang bertemu dan menemani klien di pusat data. Ada permintaan yang secara konsisten berhasil di 5 departemen.
Untuk semua kasus seperti itu, tombol "Kirim" yang terpisah muncul di antarmuka.



Korespondensi dengan klien dan kolega. Fungsi ini hanya untuk memastikan bahwa korespondensi tentang insiden tersebut tidak "bocor" ke dalam surat dan seluruh sejarah komunikasi disimpan bersama kami.

Sejauh ini, semuanya sangat minimalis. Rencananya adalah membuat editor teks lengkap dengan kemampuan untuk mengunduh file, tabel, dll.



Riwayat penunjukan dan riwayat semua kegiatan insiden. Tab ini membantu Anda menyortir masalah kontroversial dan penyelidikan internal. Saat ini, saya mengunduh laporan dari riwayat untuk memantau seberapa sering pengirim membuat kesalahan ketika menugaskan suatu peristiwa ke grup profil.



Ini adalah kisah tentang penunjukan untuk insiden internal "Pemberhentian seorang karyawan."


Sejarah insiden. Di sini kita akan tetap menghadirkan keindahan, tetapi tugas utama telah diselesaikan - semuanya dicatat.

Pengamat. Kebetulan dalam surat lamaran, klien mengikat salinan orang yang tertarik dalam salinan. Semua kawan ini akan muncul di tab "Pengamat" dan memantau pelaksanaan aplikasi ini. Mereka akan menerima ketukan tentang status permintaan, jika mereka mau, mereka akan dapat berhubungan dengan dukungan teknis kami. Di dalam perusahaan, fungsi ini juga diminati: manajer layanan dapat memenuhi setiap permintaan klien mereka dan memantau pelaksanaannya.
Daftar pengamat dapat diedit: hapus dan tambahkan yang baru.



Pola insiden. Ada banyak pertanyaan khas. Agar tidak mengisi aplikasi untuk izin atau pembersihan sampah puluhan kali sehari, kami menambahkan kemampuan untuk membuat templat kejadian. Anda hanya perlu mengklik tombol "Buat Insiden", dan templat yang sudah diisi sebelumnya akan terbuka dengan pelaksana, jenis, prioritas, dan status yang ditentukan.

Ada banyak aplikasi yang sering muncul dalam pekerjaan pusat data: putaran, tes, pemeriksaan peralatan teknik sesuai dengan daftar periksa, dll. Untuk semua ini, insiden otomatis dikonfigurasikan, yang secara otomatis jatuh ke dalam pelacak dengan frekuensi tertentu.



Analisis Tidak ada alat analitik bawaan di Remedy, tidak ada yang bisa dibongkar dengan alat biasa. Di sini kami menyediakan untuk membongkar semuanya dan segalanya untuk analisis lebih lanjut. Sebagai contoh:

• jumlah permintaan per hari;
  
• kecepatan respons;
  
• keterlambatan permintaan;
  
• jenis permintaan;
  
• memuat oleh departemen;
  
• operator pengirim bekerja;
  
• frekuensi dan kualitas masalah yang muncul dalam konteks pelanggan;
  
• berbagai dependensi, misalnya, kecepatan eksekusi pada jenis permintaan.
  

Beberapa saat kemudian kami ingin membuat dashboard dengan bagan dan grafik, sehingga tanpa bongkar muat sihir di Excel kami mendapatkan gambaran tentang apa yang terjadi dalam dukungan teknis.


Laporan dapat dihasilkan langsung di meja layanan menggunakan filter.


Bongkar data dalam berbagai format.


Anda dapat memilih bidang yang akan ditampilkan dalam unggahan.

API untuk integrasi dengan layanan internal lainnya. Dari yang sederhana: meja layanan menarik informasi dari direktori dengan daftar perusahaan klien, kontrak, daftar layanan yang dipesan dan orang yang bertanggung jawab yang dapat mengirim permintaan. Sebelumnya, Anda harus terlebih dahulu memeriksa dengan file terpisah untuk menentukan apakah penulis adalah klien dan apakah ia dapat menulis permintaan dari perusahaan.

“Bypass shift on duty” adalah salah satu dari layanan internal kami, yang dengannya meja layanan sekarang dapat berinteraksi. Ini adalah daftar periksa elektronik, tempat petugas jaga dan teknisi pemeliharaan memeriksa pusat data beberapa kali sehari untuk gangguan dan gangguan. Contohnya situasi: saat jalan memutar, petugas menemukan meja klien dengan peralatan yang tidak terpasang dengan benar. Dia hanya membuat catatan yang sesuai dalam program Bypass, dan insiden pada masalah secara otomatis tiba di meja layanan. Petugas melangkah lebih jauh di sepanjang rute bypass, dan masalah dengan penerimaan sudah mulai dipecahkan.


Suatu kejadian dapat dibuat untuk salah satu item daftar periksa.


Formulir untuk insiden di dalam perangkat lunak Bypass. Di atas, gantung insiden dalam pekerjaan pada objek yang sama.

Tentang hal-hal kecil. Semua jenis permintaan yang paling umum kami tampilkan di halaman antarmuka. Setelah memilih prioritas, pengguna melihat tenggat waktu dan bilah kemajuan, menunjukkan berapa banyak waktu yang tersisa untuk menjalankan insiden.

Implementasi

Selama operasi uji coba, kami menguji meja kerja pada aplikasi internal. Sekitar sebulan mereka dilatih di departemen AXO, konstruksi modal, produksi dan manajemen layanan. Aplikasi eksternal dan aplikasi dari departemen lain terus melalui Remedy.

Kemudian kami sepakat dengan tiga klien untuk menjalankan pemrosesan aplikasi eksternal. Di sinilah masalah pertama terjadi.

Ketika mereka baru saja mulai membuat meja layanan baru, saya menghargai harapan bahwa parser surat pintar kami akan dapat mendaftarkan permintaan, menyebarkannya melalui departemen khusus, mengajukan pesan pada masalah yang sama dalam satu kejadian. Di masa depan, ini berarti meninggalkan dispatcher pada pemrosesan permintaan tertulis. Di Remedy, orang sangat terbiasa mengandalkan korespondensi surat, ada lebih dari yang kami harapkan. Parser gagal dalam tes tes: itu bisa mencampuradukkan departemen ketika membuat permintaan, ia mendaftarkan pesan baru pada insiden yang sudah terbuka sebagai insiden baru. Ada lebih banyak kesulitan sepele: parser tidak bisa membaca surat yang datang dari surat dengan sertifikat; Saya tidak mengerti pengodean non-standar dan mengirim teks dari pertanyaan.

Saya harus menambahkan tenaga kerja manual - ruang kontrol muncul. Ini adalah api penyucian untuk semua aplikasi yang datang ke support@dtln.ru . Dari sana, operator secara manual mendistribusikan aplikasi berdasarkan departemen.



Di sisi klien, logika interaksi dengan dukungan teknis tetap sama, hanya penampilan ketukan telah berubah. Pada hari-hari awal, ada beberapa overlay dengan mereka, terutama karena detail kontak yang salah dalam direktori. Jadi salah satu klien memiliki 23 orang yang bertanggung jawab dan semuanya memiliki satu email yang sama, seperti info @. Meja layanan dengan patuh memberi tahu semua orang, memenuhi tarif harian selama satu jam dengan masuk di kotak surat ini.

Apa selanjutnya

Dalam waktu dekat - integrasi dengan Akun Saya . Semua korespondensi dan riwayat kontak akan ditampilkan di profil klien. Secara teoritis, ini adalah kesempatan untuk mengecualikan email dari komunikasi dengan dukungan teknis dan akhirnya menyeret klien ke antarmuka web kami. Mari kita lihat bagaimana itu berakar dalam kehidupan.

Implementasi aplikasi yang diparameterisasi . Ada kueri yang berisi banyak parameter dan nilai, dan penting untuk tidak mencampuradukkannya. Misalnya, ketika klien meminta untuk menambahkan sumber daya virtual ke kumpulan atau membuat mesin virtual dengan ukuran tertentu. Untuk kasus seperti itu, kami berencana membuat konstruktor dengan parameter. Ini akan secara otomatis mem-parsing permintaan klien tersebut yang diterima melalui surat. Ini akan digunakan oleh operator ketika menerima aplikasi melalui telepon.


Ini adalah apa yang tampak seperti perintah berparameter.

Evaluasi dukungan teknis. Yang terkenal "menilai layanan kami pada skala lima poin" dengan kemampuan untuk menulis dalam bentuk bebas, segala sesuatu yang dipikirkan klien tentang layanan kami.

Kami ingin mengembangkan ruang Dispatch , yang muncul sebagai penopang untuk membantu pengurai surat, di tempat kerja otomatis penuh dari operator (AWP) . Sekarang operator harus melihat ke berbagai antarmuka (akuntansi peralatan, daftar orang yang bertanggung jawab, layanan pelanggan) untuk mengumpulkan informasi yang diperlukan pada pelanggan. Namun, dalam AWP, semuanya akan berada dalam satu jendela: insiden pelanggan, kontak, kontrak, layanan yang dipesan dan parameternya, dll. Data.

Nah, jangan kehilangan harapan untuk distribusi otomatis aplikasi oleh departemen . Sekarang kami sedang memikirkan sistem hashtag untuk pengurai email.

***
Meja layanan telah beroperasi dalam mode pertempuran sejak November, dan selama ini saya telah melihat peningkatan yang stabil dalam jumlah insiden (+ 40%), terutama karena permintaan internal. Saya berani berharap bahwa ini disebabkan oleh kenyataan bahwa meja layanan baru lebih ramah dalam segala hal dan permintaan tidak lagi melewatinya.

Keuntungan lain dari meja layanan baru adalah fleksibilitas. Kami telah membuat beberapa solusi khusus untuk pelanggan individu agar dapat berintegrasi dengan meja layanan internal mereka atau sekadar beradaptasi dengan proses produksinya. Sebelumnya, dibutuhkan berbulan-bulan dan jutaan, tetapi sekarang yang diperlukan hanyalah surat untuk pengembang Anda dan 1-2 minggu tergantung pada kompleksitas tugas.