Menurut The Standish Group di AS dan Eropa untuk 2015:
- 31,1% dari semua proyek TI dihentikan dan tidak selesai;
- 52,7% dari semua proyek TI diselesaikan dengan tenggat waktu, peningkatan signifikan dalam anggaran yang direncanakan semula atau perubahan radikal dalam tujuan yang direncanakan semula;
- hanya 16,2% dari semua proyek TI yang memenuhi harapan.
Total:
83,8% (sebenarnya 8 dari 10) kegagalan versus 16,2% sukses.
Selama 10 tahun terakhir, angka-angka ini tidak berubah - ketika menerapkan sistem TI, sebuah bisnis dihadapkan dengan masalah khas yang dapat dikelompokkan sebagai berikut:
- Kesulitan dan masalah organisasi.
- Kesalahan dalam merencanakan dan mengelola proyek implementasi (anggaran, tenggat waktu, dan kesalahan lain yang terkait dengan pendekatan proyek).
- Masalah yang terkait dengan infrastruktur dan alat kerja (termasuk praktik dan sistem yang harus membantu implementasi).
Dan apa yang menyebabkan kegagalan dalam implementasi Service Desk dan sistem lain di Rusia?
Kami sedang mengembangkan sistem
Help Desk untuk mengotomatisasi semua proses layanan purna jual di perusahaan layanan . Setelah berbicara dengan lebih dari 5.000 perwakilan dari berbagai sektor layanan (usaha menengah dan kecil), kami memutuskan untuk berbagi alasan mengapa implementasi Service Desk yang gagal di Rusia / CIS dan metode untuk mengatasi sebagian besar kesulitan! Faktanya, masalah tersebut ternyata “universal” untuk implementasi sistem TI dan proyek TI.
Kami yakin ini akan memungkinkan Anda untuk mempersiapkan dan menghindari setidaknya beberapa dari mereka.
Implementasi Service Desk. Realitas Rusia
Komunikasi dengan 5000+ perusahaan jasa yang beroperasi di segmen b2b di Rusia dan negara-negara CIS tidak memberikan statistik yang akurat tentang proyek, tetapi memungkinkan kami untuk mengidentifikasi kelompok masalah yang sama (bukan tanpa spesifik lokal). Selanjutnya, kami mempertimbangkan setiap item secara lebih rinci, dengan fokus pada "perwakilan" kegagalan paling populer. Perlu dicatat bahwa klasifikasi masalah yang digunakan adalah bersyarat dan dipilih hanya untuk kenyamanan presentasi. Grup yang dipilih bersinggungan satu sama lain. Misalnya, ketakutan akan perubahan terkait erat dengan masalah organisasi, dll.
Peluru perak
“Sistem Service Desk itu sendiri akan menyelesaikan semua masalah”
Banyak yang benar-benar percaya bahwa sistem otomasi akan menyelesaikan semua masalah. Dalam proses saat ini sebagian besar perusahaan jasa, kekacauan memerintah, dan tampaknya pengenalan
Meja Layanan atau CRM akan memungkinkan Anda untuk mendapatkan kontrol penuh atas situasi mengenai penjualan atau dukungan pelanggan.
Ini adalah kesalahan besar. Ada pepatah terkenal:
"Jika perusahaan Anda memiliki kekacauan, maka hasil dari pengenalan sistem otomasi akan menjadi kekacauan otomatis .
"Tidak ada alat yang dapat memecahkan masalah internal yang mendesak. Efek dari memperkenalkan Service Desk di perusahaan dengan kematangan yang rendah tidak diragukan lagi akan memiliki dampak yang serius (misalnya, itu akan menghilangkan hilangnya aplikasi,
mengurangi keterlambatan SLA , dll.). Tetapi keberhasilan penyelesaian proyek dengan hasil yang dapat dipahami dan diukur, yang dapat dikembangkan lebih lanjut, hampir tidak mungkin dalam kasus umum tanpa mengubah komponen organisasi.
"Tarik" pada persyaratan kami
Masalah ini adalah karakteristik dari bisnis yang lebih besar dan lebih birokratis.
Sebagai aturan, proses di perusahaan tersebut telah berkembang untuk waktu yang lama, beberapa jenis skema manajemen mulai terbentuk. Di atas sistem ini terdapat otomatisasi "tambal sulam" - Meja Layanan di beberapa area tertentu, CRM berbeda di berbagai departemen, dll. Tetapi bisnis ingin mendapatkan sistem terpusat dan otomatis tunggal, yang menghubungkan semua proses satu sama lain. Kesalahannya adalah bahwa pada saat yang sama ia tidak ingin beradaptasi dengan sistem yang ada dan praktik terbaik sesuai dengan yang dikembangkan, mencoba "menarik" produk yang dipilih pada persyaratannya. Dan untuk melakukan ini sangat sulit.
Untuk mencapai hasil, bersama dengan proyek implementasi, Anda harus mengubah pendekatan untuk bekerja, melakukan perubahan organisasi dan bahkan menyingkirkan beberapa orang atau, sebaliknya, memperkenalkan peran baru di negara bagian. Dan semua ini harus dilakukan secara wajar, memahami indikator apa yang harus dicapai.
Melaksanakan Service Desk. Takut akan perubahan
"Pelanggan kami tidak begitu terbiasa dengannya."
Perusahaan jasa benar-benar mempertimbangkan sesuatu seperti ini:
"Itu tidak akan berhasil karena pelanggan kami tidak terbiasa."
Mereka bahkan tidak siap untuk mencoba mengubah skema kerja yang ada, misalnya, dengan mengusulkan mekanisme pengujian baru, lebih sederhana dan lebih nyaman untuk beberapa klien mereka. Sejak awal, mereka memiliki keyakinan bahwa pelanggan akan menolak segala sesuatu yang baru. Ini berarti bahwa tidak masuk akal untuk meluncurkan proyek, atau, sebaliknya, proyek yang diluncurkan tidak berakhir.
“Diperlukan reorganisasi”
Masalah ini sebagian besar terkait dengan pengenalan sistem meja layanan karena kompleksitas komparatif dari proses dukungan. Penolakan proyek dikaitkan dengan ketakutan akan reorganisasi. Namun seringkali, perubahan seperti itu menguntungkan bisnis. Mereka dapat didasarkan pada "praktik terbaik dan perpustakaan" di mana mereka digabungkan -
ITIL, atau pendekatan untuk mengatur manajemen layanan ITSM , tetapi usaha kecil dan menengah, tentu saja, menolak untuk menggunakan praktik "terbaik" ini.
Contoh yang bagus adalah perusahaan jasa, di mana layanan tidak lagi dilakukan oleh 2-3, tetapi oleh 10 orang atau lebih. Pada skala seperti itu, pertama, sudah ada aliran aplikasi yang besar, dan kedua, ada gradasi orang yang jelas dalam hal kompetensi dan pembayaran. Reorganisasi layanan dukungan melibatkan alokasi jalur pertama, kedua, ketiga, perubahan interaksi dengan kontraktor dan banyak lagi.
Tidak memperhitungkan reorganisasi, perusahaan takut meluncurkan proyek untuk memperkenalkan sistem layanan, atau mereka memperkenalkannya, tetapi mereka tidak mendapatkan hasil yang diinginkan (kekacauan otomatis).
“Biaya waktu nyata akan meningkat”
Perusahaan menunda implementasi alat ketika mereka menyadari bahwa biaya waktu nyata karyawan ketika bekerja dengan sistem meja layanan baru tumbuh. Dan ini benar!
Pada awalnya, Anda benar-benar harus menghabiskan lebih banyak waktu. Misalnya, Anda harus mendaftarkan 100% aplikasi, menandai tindakan yang dilakukan selama pemrosesan, menghapus biaya tenaga kerja, dll. Tetapi poin inefisiensi tidak dapat diidentifikasi tanpa memperbaiki aktivitas dan melacak metrik padanya. Dan karena itu, sebelum memulai proyek, Anda hanya perlu menjawab pertanyaan Anda, “Apa yang kami inginkan sebagai hasil dari penerapan service desk?”
Keakraban: "Kolega tidak akan senang"
Dalam bisnis Rusia, hubungan "keakraban" sangat umum. Dan semakin "rumah" sebuah perusahaan, semakin kompleks itu. Ini terutama diucapkan di perusahaan-perusahaan di pinggiran - dalam bisnis untuk 10 - 20 orang yang telah bekerja bersama untuk waktu yang lama.
Cronyism menimbulkan pertanyaan moral yang sulit ketika perubahan atau pemberhentian mereka yang bekerja dengan buruk diperlukan. Seringkali dalam situasi seperti itu, proyek ditunda, dan alat baru tidak digunakan, karena di dalam perusahaan ada ketidakpuasan atau pertanyaan yang tidak terjawab: "Bagaimana bisa begitu?"
Dalam situasi seperti itu, Anda harus memprioritaskan. Jika kroniisme lebih penting, maka tidak masuk akal untuk berpikir tentang kinerja bisnis dan kegiatan perusahaan Anda pada prinsipnya memanggil bisnis. Dan bahkan lebih memperkenalkan alat mengungkapkan kemacetan. Tetapi jika Anda membutuhkan hasil, Anda harus tegar. Implementasi dari Service Desk hanya akan memungkinkan pengambilan keputusan yang objektif dan terinformasi dalam hal dukungan layanan dan layanan pelanggan purna jual.
Kesalahan Organisasi dan Kesulitan dalam Melaksanakan Meja Layanan
Resistensi internal
Karyawan perusahaan tidak menyukai perubahan dalam cara hidup yang ada. Sebagai contoh, petugas pengirim duduk dan di sebuah majalah di sebuah pena, dengan cara kuno, menuliskan semua permohonan dari penghuni rumah tentang ketidakmampuan lift, dengan tenang minum teh. Dan di sini dia dipaksa untuk memperbaiki sesuatu dalam sistem yang tidak bisa dipahami. Secara alami, dia menolak.
Masalahnya juga terkait usia. Semakin tua tim, semakin sulit dalam hal mengadopsi format kerja baru yang berubah.
Tidak ada minat nyata dalam manajemen / pengambil keputusan (pengambil keputusan)
Sebagian besar, ini berlaku untuk bisnis menengah dan kecil. Para pemimpin perusahaan semacam itu dipaksa menjadi "multi-pekerja". Mereka menjual, dan memberikan dukungan pelanggan, dan menyelesaikan masalah birokrasi. Dan ketika mereka tidak memiliki kepentingan nyata dalam proyek, itu tidak berakhir dengan sesuatu yang baik.
Setiap proyek membutuhkan "driver." Dia dapat "datang" dari manajemen puncak - pilihan terbaik. Jika tidak, manajer menengah atau orang yang bertanggung jawab atas unit proses dalam perusahaan harus "menjual" di dalam dan bertanggung jawab atas hasilnya.
Kurang atau masalah dengan pendekatan desain
Tidak ada tim dan manajer proyek khusus
Ketika perusahaan tidak mengalokasikan orang yang bertanggung jawab atas hasil dari memperkenalkan sistem meja layanan, tidak ada yang terjadi.
Jika proyek ini kecil dan ada beberapa orang di perusahaan, tim yang berdedikasi tidak diperlukan. Tetapi harus ada manajer proyek dengan otoritas. Dia berkewajiban untuk memimpin proyek ke titik akhirnya, bertanggung jawab atas anggaran dan orang-orang, memiliki kesempatan untuk menerapkan pengaruh organisasi atau skema motivasi.
Ngomong-ngomong, perlu tidak hanya untuk memilih orang-orang dengan kekuatan dan tanggung jawab yang jelas, tetapi setidaknya sebagian untuk secara bersamaan menghapus dari mereka kegiatan di bidang lain.
Tidak ada waktu tersedia untuk mereka yang terkena dampak.
Seringkali perusahaan memiliki tim proyek yang berdedikasi dan bahkan pemimpinnya, tetapi tidak ada waktu bagi mereka yang akan terpengaruh oleh penerapan sistem desk service. Misalnya, insinyur, menjalankan aplikasi atau programmer (jika kami memasukkannya dalam proses dukungan dalam bentuk baris ketiga). Ketika waktu mereka tidak dialokasikan dan, yang paling penting, orang tidak memiliki motivasi dan pemahaman mengapa ini diperlukan, proyek ini bertumpu pada resistensi internal dan "sabotase".
Tidak ada persyaratan nyata dan kasus penggunaan (ruang lingkup proyek)
Masalah seperti itu sering ditemukan di Barat: pada awalnya tidak ada persyaratan yang jelas untuk sistem desk service atau hasil proyek. Ini mengarah, antara lain, ke proses pengambilan keputusan tanpa akhir. Pelanggan tersebut memiliki keinginan untuk mengotomatiskan segalanya - untuk mengencangkan sistem sesuai kebutuhan mereka (lebih lanjut tentang ini di atas), atau persyaratan untuk sistem terus berubah.
Pada akhirnya, proyek meninggalkan tanpa memulai: mereka menguji 20 sistem beberapa kali dan menyadari bahwa tidak ada yang cocok. Lebih buruk lagi, jika proyek diluncurkan, beberapa anggaran dan kerangka waktu ditentukan, dan kemudian persyaratan "menyebar", yang mengarah pada gangguan signifikan terhadap tenggat waktu dan biaya domestik yang "meningkat" secara serius. Pada tahap tertentu, menjadi lebih mudah untuk meninggalkannya.
Tidak ada "dampak" (Periksa - Undang-Undang)
Banyak perusahaan, setelah memperoleh hasil utama (kadang-kadang sangat baik, terutama jika tidak ada yang telah diotomatisasi sebelumnya), berhenti memperbaiki sistem dan proses yang dimaksudkan untuk diotomatisasi. Mereka berhenti mengontrol indikator dan, yang paling penting, untuk menindaklanjuti hasil kontrol ini.
Setiap proyek menyerupai "spiral." Ada yang disebut siklus Deming - Plan -> Do -> Check -> Act. Jika kita berbicara tentang Service Desk, maka salah satu tugas khas menerapkan sistem seperti itu adalah untuk mengurangi keterlambatan pada SLA. Tetapi setelah mulai bekerja, banyak perusahaan, pada prinsipnya, tidak menggunakan laporan. Dan beberapa dari mereka yang masih menggunakannya tidak merencanakan perubahan selanjutnya dalam proses mereka, yang memungkinkan mereka untuk mencapai indikator yang lebih baik. Tanpa ini, kepuasan akhir tidak dapat diperoleh dari proyek.
Kisah "kualitas / cepat / gratis"
Sampai sekarang, banyak, terutama perusahaan kecil, memiliki keyakinan bahwa Anda dapat menemukan sistem atau orang yang dapat melakukan semuanya dengan cepat, efisien dan praktis gratis. Di hadapan harapan ini, proyek itu berakhir dengan sia-sia - ternyata untuk waktu yang lama, tidak terlalu mahal, dan berkualitas buruk.
Keinginan klien untuk mengembangkan sistem Meja Layanan mereka sendiri juga terkait dengan kategori masalah ini (mengapa kami tidak perlu melakukan ini, kami menulis secara rinci dalam artikel kami). Jika perusahaan memiliki peluang untuk mengalokasikan 2-3 programmer, misalnya, selama enam bulan - setahun, maka bisnis Anda sangat buruk - bisnis tidak fokus pada apa yang seharusnya dilakukan. Di daerah-daerah yang bukan kunci untuk bisnis, lebih baik menarik orang atau menggunakan sistem "dari luar," daripada menciptakan kembali sepeda Anda.
Implementasi Service Desk. Bagaimana cara menghindari kesalahan?
Berikut adalah beberapa rekomendasi universal yang akan memungkinkan Anda menghemat waktu pada tahap peluncuran proyek dan mengimplementasikan sistem Service Desk:
- Perusahaan harus memiliki "driver" untuk proyek implementasi sistem . Pada saat yang sama , ia harus memiliki wewenang untuk membuat keputusan , termasuk yang tidak populer, dan semua peserta proyek dan mereka yang akan terpengaruh oleh sistem setelah peluncuran harus menyadari kekuatan ini.
- Penting untuk menentukan tujuan dan mencatat persyaratan (untuk sistem, proyek, hasil). Sebelum Anda mulai mencari sistem meja layanan, Anda perlu menentukan tujuan, karena jika tidak ada, epik ini mungkin tidak berakhir dengan apa pun.
- Anggaran / waktu / tim harus disorot . Semua sumber daya ini jelas tergantung pada persyaratan. Seharusnya tidak ada ilusi: keinginan untuk memperketat sistem dengan kebutuhan individu akan menyebabkan biaya tinggi (setelan sesuai pesanan selalu lebih mahal). Lingkup proyek juga menentukan waktu yang perlu dialokasikan oleh pengemudi dan peserta proyek, serta oleh semua orang yang akan terpengaruh oleh penggunaan sistem.
- Tidak perlu takut akan perubahan dan "baru" . Perubahan dapat diuji pada bagian pelanggan atau pengguna, misalnya, pada beberapa pelanggan. Ya, Anda harus menghabiskan lebih banyak waktu menata ulang struktur, terutama setelah mengidentifikasi fokus inefisiensi. Sulit dan terkadang menyakitkan, terutama mengingat kronisme. Tetapi ini perlu jika kita fokus pada efektivitas organisasi dan bisnis itu sendiri.
- Terus-menerus mengatasi perlawanan - hak untuk "menjual . " Sistem meja layanan dirancang tidak hanya untuk mengontrol pekerjaan, tetapi juga untuk membangun hubungan yang transparan dengan pelanggan. Karyawan, bahkan yang lebih tua, memahami ini dan argumen masuk akal lainnya.
- Fokus pada bisnis inti Anda . Ketika perusahaan memutuskan untuk menciptakan sepeda sendiri dalam waktu setengah tahun atau setahun, kembangkan CRM, Helpdesk, dll. - hampir selalu berakhir dengan kegagalan. Tetapi yang utama adalah indikator betapa tidak efektifnya bisnis Anda saat ini.
- Berhentilah memercayai dongeng tentang “gratis, murah, berkualitas tinggi” . Itu sendiri tidak "terbang". Masalah utama dalam memperkenalkan semua sistem adalah kesulitan organisasi dan perubahan yang harus dilakukan, jika tidak, sistem akan membawa hasil, tetapi tidak akan persis yang bisa diperoleh.
Catatan diterbitkan berdasarkan bahan dari
blog Okdesk