Bagaimana kami memilih ServiceDesk. Bagian 2

Kami terus menulis tentang pilihan sistem kami untuk mendigitalkan bisnis. Bagaimana semuanya dimulai, baca di sini.

Biarkan saya mengingatkan Anda: kami adalah perusahaan jasa yang memutuskan untuk menemukan pil ajaib untuk bisnis kami, berkat itu "kering" dan semua proses bisnis berjalan dengan lancar dan tanpa gangguan.


Kami mempertimbangkannya untuk ketersediaan fungsi yang kami butuhkan. Yang mana

3 fungsi penting bagi kami


Fitur-fitur ini jauh dari semua yang kami cari di ServiceDesk. Lihat daftar lengkap di artikel pertama kami. Di sana kami menggambarkan 3 fitur, di sini 3, sisanya - di artikel berikutnya.

Artikel ini membandingkan:

  • Kemampuan untuk menyesuaikan siklus hidup aplikasi tergantung pada panggilan masuk tanpa pemrograman. Idealnya, ini untuk menghemat waktu. Untuk satu jenis pekerjaan, tidak perlu mengoordinasikan pekerjaan dengan pelanggan, dan untuk yang lain diperlukan. Siklus hidup dapat sangat berbeda satu sama lain tergantung pada jenis aplikasi (kritis, tidak kritis, terencana, dll.). Seharusnya ada alat yang nyaman yang memungkinkan Anda untuk menandai dan mengeditnya.
  • Ubah riwayat setiap aplikasi. Kami ingin menerima sesuatu seperti arbitrase. Dalam hal ini, kita berbicara tentang kesempatan untuk mengeksplorasi seluruh kronologi kerja sama, yang sering membantu menyelesaikan masalah yang diperdebatkan. Riwayat perubahan aplikasi yang jelas sangat bagus untuk ini.
  • Penyesuaian eskalasi (transfer tanggung jawab) yang fleksibel antara karyawan. Misalnya, satu orang tidak dapat pergi ke aplikasi. Maka Anda perlu mentransfer aplikasi ke kepala, yang akan mentransfernya ke karyawan lain. Bisakah ini dengan cepat tercermin dalam sistem dan skrip yang sudah dikonfigurasi sebelumnya?

Bagaimana fitur-fitur ini diimplementasikan?

Menyiapkan siklus hidup aplikasi


Planado


Selama operasi, kita melihat LC linier sederhana: Mulai - Jeda - Akhir.



Kustomisasi tidak berfungsi. Sayang sekali.
Pada prinsipnya, sistem ini dapat digunakan untuk menyelesaikan masalah kita, tetapi tidak akan nyaman.

Okdesk


Pengaturan fleksibel. Dimungkinkan untuk membuat status baru dan menentukan transisi di antara mereka.
Antarmuka yang sederhana dan intuitif.



Kesimpulan: jika minimal, maka fungsinya dapat diterima, mis. sudah cukup. Tetapi tidak ada cara untuk membangun hubungan yang fleksibel antara status - kita akan kehilangan fungsi ini.

Grotem


Pengaturan aplikasi LC tidak disediakan.

BPM Online


Pengaturan yang sangat fleksibel. Dimungkinkan untuk membuat status baru dan menentukan transisi di antara mereka. Pengaturan apa pun melalui fungsionalitas bawaan.



Hubex


Dimungkinkan untuk membuat dan mengonfigurasi siklus hidup aplikasi secara individual. Status, tahapan, dan transisi dapat disesuaikan dan dapat disesuaikan untuk perusahaan.



Naumen


Dimungkinkan untuk membuat status baru dan menentukan transisi di antara mereka.
Konfigurasi siklus hidup yang fleksibel. Mengatur bidang visibilitas dan wajib tergantung pada status. Semua ini dimungkinkan dalam antarmuka teknolog.



Tetapi sekali lagi, antarmuka tidak cocok untuk semua orang.

Ubah riwayat


Planado


Sejarah seperti itu tidak diamati. Hanya memperbaiki waktu ketika mengubah status.



Ini buruk, karena arbitrase tidak akan berhasil. Refleksi perubahan semacam itu membutuhkan tekanan tambahan dan penarikan kembali apa yang dulu dan kemudian. Dan jika Anda tidak ingat, Anda kehilangan arbitrase.

Jelas, ini tidak cocok untuk kita.

Okdesk


Cerita standar yang cantik. Ini mencatat ketika perubahan dan status aplikasi (baik sebelumnya dan baru) terjadi.

Menyenangkan - setelah pemeriksaan yang teliti, jelas siapa yang mengubah status aplikasi. Tapi ini juga minus - Anda dapat mempertimbangkan pembuat perubahan hanya jika Anda melihat dari dekat (karena penulis hanya ditandai dalam teks perubahan, dan bukan di kolom terpisah).



Apakah itu cocok untuk kita? Tidak, karena cerita seperti itu membutuhkan banyak waktu untuk menyelesaikannya. Setidaknya, saya ingin tampilan riwayat yang lebih nyaman untuk mencari informasi dengan cepat.

Grotem


Sistem menyimpan riwayat perubahan aplikasi.
Dalam riwayat, Anda dapat melihat opsi berikut:
- Tanggal perubahan
- Status
- Penulis perubahan



Apakah fungsi ini cocok untuk kita? Ya itu mungkin.

BPM Online


Memiliki beberapa tampilan pada perubahan.

Dalam sistem Anda dapat melihat riwayat perubahan untuk setiap tahap aplikasi:

- siapa yang membuat perubahan,
- ketika dia melakukannya,
- yang mana



Apakah fungsi sistem ini cocok untuk kita? Mungkin Kami akan melihat lebih jauh.

Hubex


"Ubah Riwayat" disimpan di bagian yang sesuai di dalam aplikasi.

Informasi berikut disimpan dalam sejarah:

- status aplikasi,
- tahap siklus hidup aplikasi,
- siapa yang membuat perubahan,
- ketika dia membuat perubahan,
- jam berapa perubahan.



Di sini Anda dapat menemukan informasi tentang status aplikasi, masa berlaku dan status aplikasi.



Bonus yang sangat bagus: dalam sejarah perubahan Anda dapat melihat apakah ada karyawan di fasilitas tersebut atau tidak. Dalam status permintaan (tengah layar), sistem menunjukkan di mana perubahan dilakukan.
Apakah fungsi ini cocok untuk perusahaan kami? Saya kira begitu, tetapi ada satu solusi lagi.

Naumen


Cerita yang cukup standar.

Perbaikan sebagian besar perubahan pada atribut aplikasi telah diterapkan:

- Tanggal amandemen,
- Deskripsi perubahan,
- Penulis perubahan.

Versi berikutnya mengharapkan penambahan geolokasi saat mengubah status.



Menyiapkan eskalasi otomatis (transfer tanggung jawab)


Idealnya, saya ingin mengotomatiskan proses ini sehingga sistem itu sendiri berubah dan memberi tahu orang yang bertanggung jawab atas aplikasi, tergantung pada skenario yang diberikan.

Misalnya, jika aplikasi telah bergantung pada status "Baru" selama lebih dari 2 jam atau ketika mengubah status aplikasi menjadi "Penolakan pelaksana" - dapatkah sistem secara mandiri mentransfer aplikasi ke kepala organisasi?

Planado


Tidak ada pengaturan eskalasi dalam bentuk apa pun. Sayangnya, ini mudah, karena perusahaan dapat kehilangan sebagian dari pendapatannya karena kehilangan pelanggan. Sebuah minus besar ...

Okdesk


Eskalasi diimplementasikan hanya dalam bentuk satu peringatan email, Anda dapat mengonfigurasi waktu peringatan.



Ini tidak sepenuhnya cocok untuk kita, karena saya ingin memberi tahu kepala tidak hanya melalui e-mail.

Grotem


Dalam versi khas sistem, fungsi ini tidak disediakan. Kustomisasi individu saja.
Pada prinsipnya, Anda dapat mempertimbangkan opsi ini, tetapi saya tidak ingin menghabiskan uang ekstra.

BPM Online


Eskalasi dikonfigurasikan dalam perancang proses bisnis, pada tab "Formulir".



Di sini Anda dapat menentukan kondisi pelaksanaan tugas atau periode waktu di mana tugas harus diselesaikan. Kalau tidak, manajemen diberitahu dalam sistem.

Apakah ini cocok untuk kita? Tidak, karena manajemen tidak selalu "duduk" dalam sistem, dan perlu pemberitahuan melalui saluran lain (setidaknya e-mail, SMS).

Hubex


Dalam sistem, Anda dapat dengan mudah mengkonfigurasi eskalasi - kondisi untuk mengirim pemberitahuan, teks pemberitahuan dan fungsi lainnya dikonfigurasikan.



Pemberitahuan tersedia melalui pesan push atau email.
Cocok untuk kita? Mungkin, tetapi metode notifikasi tidak cukup.

Naumen


Menerapkan sejumlah besar pengaturan untuk mekanisme eskalasi. Ada email, SMS, dan pemberitahuan push.





Sistem ini pasti cocok untuk organisasi kami.

Dilanjutkan ...


Ini semua tentu saja bagus. Tapi ada banyak materi. Saya tidak ingin membuat pembaca terhormat dengan tulisan saya. Dan tidak ada waktu untuk kelas fiksi.

Pada akhirnya, kita bukan Daria Dantsova, untuk memberi cap seluruh buku beberapa lembar sehari. Karena itu, kami akan mengeluarkan informasi secara bertahap.

Untuk koneksi!




Bagian 1
Bagian 3

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


All Articles