Bayangkan Anda menelepon pertanyaan ke call center bank dan dapatkan satu jawaban. Kemudian datang ke titik penjualan, tetapi informasi yang diperoleh sebelumnya tidak relevan. Untuk memastikan bahwa perbedaan ini dijamin dapat dihindari, kami memutuskan untuk meninggalkan solusi yang ada dibuat di bank di SharePoint, memproses semua konten, mengidentifikasi sumber data dan konsumen, dan mengemas kembali semua informasi yang diperlukan ke dalam sistem manajemen pengetahuan baru - sama untuk semua departemen. Dalam posting ini kami akan membagikan pengalaman kami.
Pernyataan masalah dan pilihan solusi
Untuk memulainya, semua informasi yang terkait dengan layanan pelanggan, produk dan layanan kami, harus disatukan. Secara historis, pengetahuan disimpan dalam tiga basis pengetahuan besar yang diciptakan pada waktu yang berbeda, pada kenyataannya, di bank yang berbeda. Pada saat yang sama, salah satu persyaratan utama adalah kemampuan untuk menyediakan jumlah data yang berbeda - misalnya, untuk titik penjualan dan untuk ATP (call center). Dalam kasus pertama, informasi rinci penting: ketika orang datang ke departemen offline, mereka berharap mendengar semua detail tentang masalah yang menarik. Dalam kasus kedua, sebaliknya, informasi singkat sudah cukup - yang utama adalah bahwa informasi itu diberikan dengan cepat dan jelas.
Tugas itu diperumit oleh fakta bahwa kami memiliki sebanyak enam pelanggan internal. Dan, karenanya, berbagai jenis persyaratan. Setiap orang memiliki kriteria berbeda mengenai fungsionalitas, kinerja, dan dukungan. Misalnya, keberadaan SSO, integrasi dengan Active Directory, dll. Kemampuan implementasi tim yang cepat adalah penting. Kami berharap bahwa sistem baru akan mengurangi waktu layanan untuk 25% panggilan ke pusat panggilan 5 detik. Ini juga akan mengurangi waktu pelatihan. Sebelumnya, 3% dari seluruh waktu kerja dihabiskan untuk itu - dan ketika menyangkut lebih dari 30.000 pekerja, biaya yang dikeluarkan cukup besar.
Selain itu, selama proyek, VTB berada pada tahap menggabungkan dua bank besar dalam strukturnya, dan klien dari sistem masa depan berada di subnet yang berbeda, di segmen yang berbeda. Semua ini harus digabungkan dan diberikan kepada karyawan yang bekerja dengan sistem, akses ujung ke ujung, dengan mempertimbangkan peran akun, berbagai tingkat akses ke informasi, dll. Itu diperlukan untuk menyelesaikan banyak masalah infrastruktur tambahan.
Kami menempatkan semua persyaratan dan kriteria yang diperlukan ke dalam satu tabel penilaian. Kami melihat semua solusi utama yang ada di pasar, baik Rusia dan asing, mengunggah bagian dari konten kami ke dalamnya, dan mengevaluasi apa yang berhasil. Dan pada akhirnya, kami menetapkan sistem manajemen pengetahuan terpadu dari KMS Lighthouse. Dengan perkenalan, kami dibantu oleh tim DIS Group, yang menawarkan Mercusuar KMS di pasar Rusia.
2500 artikel dalam 16 templat untuk 60 ribu pengguna
Ada dua entitas utama dalam sistem manajemen pengetahuan baru kami - "templat" dan "artikel". Artikel adalah halaman yang diformalkan dengan informasi. Artikel yang sama terlihat berbeda untuk semua grup peran pengguna (karyawan bank). Grup dibentuk tergantung pada afiliasi organisasi, fungsional atau bisnis karyawan.
Setelah menganalisis konten yang kami miliki, kami menyadari bahwa kami berurusan dengan 2500 artikel. Lautan informasi ini perlu diurai menjadi jumlah minimum templat. Selain itu, artikel-artikel tersebut seharusnya mempertahankan fleksibilitas yang dijelaskan di atas. Ada banyak pekerjaan manual untuk membuat template, koordinasi dan rekonsiliasi. Tetapi pada akhirnya, saya berhasil memenuhi 16 templat - untuk 2.500 artikel ini adalah tingkat sistematisasi yang baik.
Kerjakan konten
16 templat didistribusikan dalam tiga grup pengelola konten. Grup pertama bertanggung jawab atas konten yang terkait dengan pusat panggilan. Yang kedua adalah untuk produk, layanan, dan informasi terkait. Yang ketiga adalah blok konten unit operasi (DOPB), kantor pusat kami. Selain itu, kami memiliki unit metodologis yang beroperasi di tingkat bank. Hampir semua informasi bank melewatinya, seperti melalui filter, dan sebagai hasilnya, hanya informasi yang harus ditempatkan dalam basis pengetahuan tetap ada.
Kami membahas pembagian yang lebih kompleks. Berpikir untuk memperkenalkan "pemilik" kelompok yang bertanggung jawab atas proses dan sistem. Kami membahas posisi "pemimpin redaksi", yang akan memverifikasi semua perubahan. Tetapi pada akhirnya, kami memutuskan untuk fokus pada tiga kelompok, karena kontennya terbagi dengan jelas di antara mereka.
KMS Lighthouse memungkinkan Anda membangun beberapa level koordinasi dengan cepat, tetapi kami memutuskan untuk tidak mempersulit sistem ini, dan pada level manajer konten kami membuat dua level - mereka yang menulis dan mereka yang menerbitkan. Pada tingkat terakhir, mereka yang bertanggung jawab atas semua konten dalam grup mereka menonjol. Benar, di sini muncul pertanyaan untuk membuat materi tentang penjualan yang berhasil ke divisi makanan, tetapi sejauh ini mereka memutuskan untuk meninggalkan semuanya apa adanya.
Dengan demikian, basis pengetahuan dapat dikembangkan tanpa penundaan. Misalkan departemen makanan ingin segera memposting informasi tentang produk baru. Mengirim permintaan melalui surat ke pengelola konten: "Kolega, kami perlu memposting artikel ini di sini." Setelah memposting melalui mekanisme umpan balik, penyempurnaan sedang berlangsung: di suatu tempat, informasi mungkin tidak cukup, di suatu tempat ada sesuatu yang tidak sesuai dengan templat. Demikian seterusnya hingga unit dan pengelola konten puas. Sekarang kami hanya memperkenalkan elemen-elemen yang diperlukan untuk interaksi ini: pemberitahuan, survei, formulir persetujuan. Jika artikel yang dibuat mencakup area berbagai kelompok pengelola konten, maka setiap orang menjadi bertanggung jawab atas tab mereka sendiri.
Server aplikasi terpisah dialokasikan untuk pengelola konten, tempat Anda dapat mengedit artikel atau membuat yang baru menggunakan templat yang ada. Di sini Anda dapat memperoleh statistik yang diperlukan tentang permintaan pencarian, relevansi jawaban, konversi, dll. Artikel tidak hanya dapat diubah, tetapi juga dioptimalkan - misalnya, membuat tag meta untuk meningkatkan pencarian. Selain itu, pencarian dapat ditingkatkan dengan menambahkan artikel tertentu secara paksa ke permintaan tertentu. Ini disebut "pilihan editor", saat mencari, pengguna melihat materi tersebut di kolom terpisah.
Pencarian Basis
Di SharePoint, orang terbiasa dengan struktur pohon penyajian informasi dan berinteraksi dengan tab. KMS Lighthouse melibatkan penggunaan pencarian penuh. Ketika 60 ribu pengguna bekerja dengan sistem (rata-rata sekitar 1600 sekaligus), ada baiknya memikirkan keseimbangan beban. Sekarang KMS Lighthouse beroperasi di 10 server. Masing-masing menggunakan dua mesin virtual. Sekelompok 20 mesin virtual bekerja. Di antara mereka adalah penyeimbang bank.
Pencarian didasarkan pada tiga mesin pencari yang mengindeks semua konten. Indeks pencarian dibuat dengan mempertimbangkan permintaan masuk akun, frekuensinya. Relevansi jawaban dan posisi mereka dalam hasil keluaran tergantung pada ini. Lighthouse menganalisis permintaan dan dapat menyajikannya dalam bentuk 16 laporan berbeda, dengan bantuan manajer konten yang bekerja untuk mengisi sistem.
Fitur tambahan
Semua karyawan yang bekerja dengan sistem dibagi menjadi sekitar 35 grup peran. Masing-masing memiliki akses ke bagian-bagian tertentu dari artikel. Seorang pengguna dapat berada di beberapa grup - lalu dia melihat konten untuk semua grup ini sekaligus.
Grup terintegrasi dengan gateway email dan SMS. Ketika bekerja dengan klien bank, seorang karyawan dapat dengan cepat mengiriminya informasi yang diperlukan - misalnya, tepat saat konsultasi telepon. Jika, tentu saja, informasi dapat dikirim; artikel tentang pengungkapan (dan cetak penerimaan) menunjukkan atribut individual. Tidak perlu menulis ulang dan menyalin-menempelkan apa pun.
Yandex.Maps juga terintegrasi ke dalam basis pengetahuan, di mana karyawan melihat betapa sibuknya departemen tertentu. Informasi diperbarui setiap setengah jam. Jadi, setelah menentukan di departemen mana klien dapat menerima layanan ini atau itu, karyawan dapat menyarankan di mana tepatnya lebih baik untuk mengatasi untuk menghemat waktu.
KMS Lighthouse terintegrasi dengan sistem front-end kami dan dapat dibawa langsung ke antarmuka sebagai widget. Di dalamnya, Anda dapat membuat permintaan cepat dan langsung pergi ke artikel - seperti di mesin pencari apa pun.
Beginilah basis pengetahuan baru kami diatur. Sekarang kami sedang menyelesaikannya dan berharap bahwa tidak hanya karyawan tetapi juga klien VTB akan menghargai efek positif dari implementasi KMS Lighthouse.
Sebagai kesimpulan, kami ingin berbagi kegembiraan kami. Pada bulan Januari, Wikipedia Bisnis kami diumumkan sebagai proyek tahun ini menurut Global CIO. Kami akan terus memberi Anda informasi dan memberi tahu apa yang baru kami kencangkan dan bagaimana hal itu membantu pekerjaan.