Karyawan tidak menginginkan perangkat lunak baru - pergi sesekali atau mengubah jalur mereka?

Software leapfrog akan segera menjadi penyakit yang sangat umum bagi perusahaan. Mengubah satu peranti lunak ke peranti lunak lain karena setiap hal kecil, beralih dari satu teknologi ke teknologi lainnya, bereksperimen dalam bisnis yang hidup menjadi norma. Pada saat yang sama, perang saudara yang sebenarnya dimulai di kantor: gerakan perlawanan terhadap pengenalan sedang dibentuk, para partisan sedang melakukan pekerjaan subversif terhadap sistem baru, mata-mata mempromosikan dunia baru yang berani dengan perangkat lunak baru, manajemen dari mobil lapis baja siaran portal perusahaan tentang perdamaian, pekerjaan, KPI. Sebuah revolusi biasanya berakhir dengan kegagalan penuh salah satu pihak.

Kami tahu hampir semua hal tentang implementasi, jadi kami akan mencoba mencari cara untuk mengubah revolusi menjadi evolusi dan membuat implementasi berguna dan tanpa rasa sakit mungkin. Ya, atau setidaknya memberi tahu Anda apa yang bisa Anda lakukan dalam proses.


Visualisasi ideal dari pengadopsian perangkat lunak baru oleh karyawan. Sumber - Yandex.Gambar

Konsultan asing akan memulai artikel ini seperti ini: "Jika Anda menawarkan karyawan Anda perangkat lunak berkualitas tinggi yang dapat meningkatkan pekerjaan mereka, memiliki dampak kualitatif pada kinerja, adopsi program atau sistem baru akan terjadi secara alami." Tapi kami bersama Anda di Rusia, jadi pertanyaan tentang karyawan yang mencurigakan dan suka berperang sangat relevan. Transisi alami tidak akan berfungsi, bahkan dengan perangkat lunak minimal seperti messenger perusahaan atau softphone.

Dari mana masalah tumbuh?

Hari ini, setiap perusahaan memiliki kebun binatang seluruh perangkat lunak (kami mengambil kasus umum, karena jumlah perangkat lunak di perusahaan IT lebih dari dua atau tiga, dan masalah adaptasi tumpang tindih sebagian dan sangat spesifik): sistem manajemen proyek, CRM / ERP, klien email, pengirim pesan instan, portal perusahaan, dll. Dan ini tidak termasuk fakta bahwa ada perusahaan di mana bahkan transisi dari peramban ke peramban dilakukan oleh seluruh tim tanpa kecuali (dan ada juga tim yang sepenuhnya duduk di Internet Explorer Edge). Dalam kasus umum, ada beberapa situasi di mana artikel kami mungkin berguna:

• proses otomatisasi utama dari kelompok tugas tertentu terjadi: CRM / ERP pertama kali diperkenalkan, portal perusahaan dibuka, sistem untuk dukungan teknis diinstal, dan sebagainya.;
  
• ada penggantian satu perangkat lunak dengan yang lain karena beberapa alasan: keusangan, persyaratan baru, penskalaan, perubahan kegiatan, dll.;
  
• modul sistem yang ada sedang dikembangkan untuk pengembangan dan pertumbuhan (misalnya, perusahaan membuka produksi dan memutuskan untuk beralih dari RegionSoft CRM Professional ke RegionSoft CRM Enterprise Plus dengan fungsi maksimal);
  
• Ada antarmuka serius dan pembaruan perangkat lunak fungsional.
  

Tentu saja, dua kasus pertama jauh lebih akut dan khas dalam manifestasinya, memberikan perhatian khusus kepada mereka.

Jadi, sebelum Anda mulai bekerja dengan tim (yang sudah menduga bahwa itu adalah alasan yang baik untuk perubahan, dan akan segera ada perubahan), cobalah untuk memahami apa alasan sebenarnya dari perubahan perangkat lunak itu dan apakah Anda setuju bahwa perubahan tersebut sangat perlu.

• Sulit untuk bekerja dalam program lama: mahal, tidak nyaman, tidak berfungsi, tidak lagi memenuhi persyaratan Anda, tidak cocok untuk skala Anda, dll. Ini adalah kebutuhan obyektif.
  
• Vendor berhenti mendukung sistem, atau dukungan dan perbaikan berubah menjadi serangkaian persetujuan tanpa akhir dan menarik uang. Jika biaya Anda telah meningkat secara signifikan, dan di masa depan mereka berjanji untuk meningkat - tidak ada yang menunggu, Anda perlu memotongnya. Ya, sistem baru juga akan membutuhkan biaya, tetapi pada akhirnya, optimasi akan lebih murah daripada dukungan seperti itu.
  
• Perubahan perangkat lunak - keinginan satu orang atau sekelompok karyawan. Sebagai contoh, CTO menginginkan kemunduran dan melobi untuk pengenalan sistem baru yang lebih mahal - ini terjadi di perusahaan besar. Contoh lain: manajer proyek menganjurkan mengubah Asana ke Basecamp, kemudian Basecamp ke Jira, kompleks Jira menjadi Wrike. Seringkali, satu-satunya motif untuk migrasi tersebut adalah untuk menunjukkan kerja keras mereka dan mempertahankan posisi mereka. Dalam kasus seperti itu, perlu untuk menentukan tingkat kebutuhan, motif dan validitas dan, sebagai suatu peraturan, menolak perubahan dalam keputusan yang disengaja.
  

Kita berbicara tentang alasan transisi dari satu perangkat lunak ke perangkat lunak lain, dan bukan tentang otomatisasi primer - hanya karena otomasi merupakan hal yang perlu dilakukan. Jika sesuatu dilakukan secara manual dan rutin di perusahaan Anda, tetapi dapat diotomatisasi, Anda hanya kehilangan waktu, uang, dan, kemungkinan besar, data perusahaan yang berharga. Otomatiskan itu!

Bagaimana saya bisa pergi: lompatan besar atau harimau berjongkok?

Dalam praktik dunia, ada tiga strategi utama untuk beralih ke perangkat lunak baru, beradaptasi dengannya - dan mereka tampaknya sangat cocok untuk kita, jadi kita tidak akan menemukan kembali roda.

Big bang

Penerimaan dengan metode Big Bang adalah transisi yang paling sulit, ketika Anda menetapkan tanggal yang tepat dan melakukan migrasi yang tajam, menonaktifkan perangkat lunak lama hingga 100%.

Pro

+ Semua bekerja dalam satu sistem, tidak perlu menyinkronkan data, karyawan tidak perlu memonitor dua antarmuka sekaligus.
+ Kesederhanaan untuk administrator - satu migrasi, satu tugas, dukungan satu sistem.
+ Semua perubahan yang mungkin terjadi pada satu titik waktu dan segera terlihat - tidak perlu mengisolasi apa dan dalam proporsi apa yang memengaruhi produktivitas, kecepatan pengembangan, penjualan, dll.

Cons

- Berhasil hanya bekerja dengan perangkat lunak sederhana: obrolan, portal perusahaan, pengirim pesan instan. Bahkan email sudah dapat gagal, belum lagi sistem manajemen proyek, CRM / ERP, dan sistem serius lainnya.
- Migrasi "eksplosif" dari sistem besar ke sistem lain pasti akan menyebabkan kekacauan.

Hal yang paling penting untuk jenis transisi ini ke lingkungan kerja baru adalah pelatihan.

Berjalan paralel

Adaptasi paralel dengan perangkat lunak adalah cara transisi yang lebih lembut dan lebih universal, di mana periode waktu ditetapkan di mana kedua sistem akan beroperasi secara bersamaan.

Pro

+ Pengguna memiliki cukup waktu untuk membiasakan diri dengan perangkat lunak baru, dengan cepat bekerja di yang lama, untuk menemukan paralel, untuk mempelajari logika interaksi baru dengan antarmuka.
+ Jika terjadi masalah yang tiba-tiba, karyawan terus bekerja dalam sistem yang lama.
+ Pelatihan pengguna kurang ketat dan umumnya lebih murah.
+ Praktis tidak ada reaksi negatif dari karyawan - setelah semua, mereka tidak kehilangan alat atau cara bisnis yang biasa (jika otomatisasi terjadi untuk pertama kalinya).

Cons

- Masalah administrasi: dukungan untuk kedua sistem, sinkronisasi data, manajemen keamanan dalam dua aplikasi sekaligus.
- Proses transisi tidak terbatas - karyawan menyadari bahwa mereka memiliki persediaan yang hampir selamanya, dan Anda dapat sedikit lebih lama menggunakan antarmuka yang akrab.
- Kerancuan pengguna - dua antarmuka membingungkan dan menyebabkan kesalahan dalam pekerjaan dan data.
- Uang. Anda membayar kedua sistem.

Adaptasi bertahap

Adaptasi selangkah demi selangkah adalah cara paling ringan untuk beralih ke perangkat lunak baru. Transisi dilakukan secara fungsional, dalam periode waktu yang disepakati dan oleh departemen (misalnya, mulai 1 Juni kami hanya menambahkan pelanggan baru ke sistem CRM baru, mulai 20 Juni kami melakukan transaksi dalam sistem baru, kami mentransfer kalender dan kasing hingga 1 Agustus, dan kami selesai pada 30 September migrasi adalah deskripsi yang sangat kasar, tetapi umumnya jelas).

Pro

+ Transisi terorganisir, beban terdistribusi pada administrator dan pakar internal.
+ Pelatihan yang lebih bijaksana dan mendalam.
+ Tidak ada penolakan terhadap perubahan, karena mereka terjadi selembut mungkin.

Kontra - hampir sama dengan transisi paralel.

Jadi sekarang, hanya transisi bertahap?

Pertanyaan logis, setuju. Mengapa mendapat masalah tambahan saat Anda dapat membuat jadwal dan bertindak sesuai dengan rencana yang jelas? Padahal, tidak semuanya begitu sederhana.

• Kompleksitas perangkat lunak: jika kita berbicara tentang perangkat lunak yang kompleks (misalnya, sistem CRM ), maka fase adaptasi lebih cocok. Jika perangkat lunaknya sederhana (messenger, portal perusahaan), maka modelnya cocok ketika Anda mengumumkan tanggal dan memangkas perangkat lunak lama pada hari yang ditentukan (jika Anda beruntung, karyawan akan dapat mengeluarkan semua informasi yang mereka butuhkan, dan jika Anda tidak mengandalkan keberuntungan, maka Anda perlu memberikan impor otomatis data yang diperlukan dari sistem lama ke yang baru, jika ada kemampuan teknis).
  
• Tingkat risiko bagi perusahaan: semakin berisiko implementasinya, semakin lambat seharusnya. Di sisi lain, penundaan juga merupakan risiko: misalnya, Anda beralih dari satu sistem CRM ke sistem lainnya, dan selama masa transisi Anda dipaksa untuk membayar keduanya, sehingga meningkatkan biaya dan biaya untuk memperkenalkan sistem baru, yang berarti bahwa periode pembayaran kembali diperpanjang.
  
• Jumlah karyawan: big bang jelas tidak cocok jika perlu untuk skala dan konfigurasi banyak profil pengguna. Meskipun ada kalanya implementasi yang sangat cepat untuk perusahaan besar itu bagus. Opsi ini mungkin cocok untuk sistem yang digunakan oleh banyak karyawan, tetapi mereka mungkin tidak memiliki persyaratan, karena kustomisasi tidak diharapkan. Tetapi sekali lagi, ini adalah ledakan besar bagi pengguna akhir dan pekerjaan bertahap besar untuk layanan TI yang sama (misalnya, penagihan atau sistem bandwidth).
  
• Fitur implementasi perangkat lunak yang dipilih (revisi, dll.) Kadang-kadang implementasi pada awalnya bertahap - dengan pengumpulan persyaratan, penyempurnaan, pelatihan, dll. Misalnya, sistem CRM selalu diterapkan secara bertahap, dan jika seseorang menjanjikan Anda untuk "menerapkan dan mengkonfigurasi dalam 3 hari atau bahkan 3 jam", ingat artikel ini dan memotong layanan seperti: instalasi ≠ implementasi.
  

Sekali lagi, bahkan mengetahui parameter yang tercantum, seseorang tidak dapat secara pasti mengambil satu jalur atau lainnya. Evaluasi lingkungan perusahaan Anda - ini akan membantu untuk secara simultan memahami keseimbangan kekuatan dan menentukan model mana (atau kombinasi dari beberapa elemen mereka) yang cocok untuk Anda.

Agen Pengaruh: Revolusi atau Evolusi

Hal pertama yang harus Anda perhatikan adalah karyawan yang akan dirugikan oleh pengenalan perangkat lunak baru. Sebenarnya, masalah yang kita pertimbangkan sekarang adalah faktor manusia murni, sehingga analisis dampak terhadap karyawan tidak dapat dihindari. Kami telah menyebutkan beberapa dari mereka di atas.

• Eksekutif perusahaan menentukan bagaimana perangkat lunak baru akan diadopsi secara umum. Dan di sini tidak ada tempat untuk pidato iklan dan pidato berapi-api - penting untuk menunjukkan dengan tepat kebutuhan akan perubahan, untuk membawa gagasan bahwa ini hanyalah pilihan alat yang lebih dingin dan lebih nyaman, sama seperti mengganti laptop lama. Kesalahan terbesar yang dibuat oleh manajemen dalam situasi seperti ini adalah mencuci tangan dan melenyapkan diri mereka sendiri: jika bos tidak membutuhkan otomatisasi perusahaan, mengapa karyawan harus tertarik dengan hal itu? Jadilah dalam proses.
  
• Kepala departemen (manajer proyek) adalah penghubung antara, yang harus dilibatkan dalam semua proses, mengelola ketidakpuasan, menunjukkan kehendak dan menyelesaikan setiap keberatan rekan kerja, melakukan pelatihan yang berkualitas dan mendalam.
  
• Layanan TI (atau administrator sistem) - sekilas, ini adalah burung awal Anda, yang paling mudah beradaptasi dan adaptif, tetapi ... tidak. Seringkali, terutama di perusahaan kecil dan menengah, administrator sistem menentang perubahan (peningkatan) infrastruktur TI, dan ini bukan karena alasan teknis, tetapi karena kemalasan dan keengganan untuk bekerja. Dan siapa di antara kita yang tidak mencari cara untuk melandai dari pekerjaan? Tapi jangan sampai ini merugikan seluruh perusahaan.
  
• Pengguna akhir, pada umumnya, ingin bekerja dengan baik dan nyaman di satu sisi, dan, seperti orang yang masih hidup, mereka takut akan perubahan. Argumen utama untuk mereka adalah jujur ​​dan sederhana: mengapa kita memperkenalkan / mengubah, apa perbatasan kontrol, bagaimana pekerjaan akan dievaluasi, apa yang akan berubah dan apa risikonya (omong-omong, risiko harus dihargai oleh semua orang - meskipun kita adalah vendor sistem CRM , kami tidak berani mengatakan bahwa semuanya selalu berjalan dengan lancar: ada risiko dalam setiap proses dalam bisnis).
  
• "Otoritas" di dalam perusahaan adalah pendukung yang dapat memengaruhi karyawan lain. Ini belum tentu orang dengan posisi tinggi atau banyak pengalaman - dalam hal bekerja dengan perangkat lunak, "otoritas" dapat berubah menjadi orang yang tahu segalanya, yang, misalnya, membaca ulang Habr dan mulai mengintimidasi semua orang dengan bagaimana semuanya akan menjadi buruk. Bahkan mungkin tidak memiliki tujuan untuk merusak proses implementasi atau transisi, - hanya pamer dan semangat perlawanan - dan karyawan akan percaya padanya. Penting untuk bekerja dengan karyawan seperti itu: untuk mengklarifikasi, untuk bertanya, dalam kasus yang sangat parah, untuk memberi petunjuk pada konsekuensi.
  

Ada resep universal untuk memeriksa apakah pengguna benar-benar takut akan sesuatu atau mereka memiliki kelompok paranoia yang dikepalai oleh pemimpin yang cerdas. Tanyakan kepada mereka tentang alasan ketidakpuasan, tentang ketakutan - jika ini bukan pengalaman atau pendapat pribadi, argumen akan memercikkan 3-4 pertanyaan klarifikasi.

Dua faktor penting untuk berhasil mengatasi "gerakan perlawanan".

1. Memberikan pelatihan: vendor dan internal. Pastikan bahwa karyawan benar-benar memahami, mempelajari segala sesuatu dan siap untuk mulai bekerja terlepas dari tingkat pelatihannya. Atribut pelatihan yang wajib dicetak dan instruksi elektronik (peraturan) dan dokumentasi paling lengkap tentang sistem (vendor yang menghargai diri sendiri mengeluarkannya bersama dengan perangkat lunak dan menyediakannya secara gratis).
   
2. Cari pendukung dan pilih influencer. Pakar internal dan pengikut awal adalah dukungan Anda, yang akan mendidik dan menghilangkan keraguan. Sebagai aturan, karyawan sendiri senang membantu rekan kerja, memperkenalkan mereka ke perangkat lunak baru. Tugas Anda adalah membongkar sementara waktu dari tempat kerja atau memberi mereka upah yang cukup untuk barang baru.
   

Apa yang perlu Anda perhatikan?

1. Seberapa maju karyawan yang terpengaruh oleh perubahan? (Secara relatif, jika besok mereka akan menciptakan program akuntansi baru, Tuhan melarang Anda masuk ke akuntansi dengan wanita di atas 50 dan menawarkan transisi dari 1C - Anda tidak akan keluar hidup-hidup).
   
2. Berapa banyak proses kerja akan terpengaruh? Ini adalah satu hal untuk mengubah messenger di perusahaan yang terdiri dari 100 orang, itu lain untuk memperkenalkan sistem CRM baru yang berfungsi sebagai inti dari proses utama perusahaan (dan itu bukan hanya penjualan, misalnya, pengenalan RegionSoft CRM dalam edisi senior yang memengaruhi produksi dan gudang, dan pemasaran, dan manajer puncak yang bersama-sama dengan tim akan membangun proses bisnis otomatis).
   
3. Apakah pelatihan diberikan dan di tingkat apa?
   

Satu-satunya transisi logis dalam sistem pemikiran perusahaan

Apa yang akan menyelamatkan transisi / implementasi perangkat lunak baru?

Sebelum Anda memberi tahu saya poin kunci apa yang akan membantu Anda bergerak dengan nyaman ke perangkat lunak baru, kami akan memusatkan perhatian Anda pada satu titik. Ada sesuatu yang pasti tidak perlu Anda lakukan - Anda tidak perlu menekan karyawan dan "memotivasi" mereka dengan perampasan, sanksi administrasi dan disiplin. Proses tidak akan berjalan lebih baik dari ini, tetapi sikap karyawan akan memburuk: jika mereka mendorongnya, itu berarti bahwa akan ada kontrol; kali dipaksa, maka jangan menghargai minat kita; karena mereka dipaksakan secara paksa, itu berarti bahwa mereka tidak mempercayai kami dan pekerjaan kami. Karena itu, kami melakukan segalanya dengan disiplin, jelas, kompeten, tetapi tanpa tekanan dan pemaksaan yang berlebihan.

Anda harus memiliki rencana tindakan terperinci.

Itu semua mungkin tidak, tetapi rencananya harus. Selain itu, rencana tersebut dapat diperbaiki, diperbarui, jelas, dan tak terhindarkan, sementara tersedia untuk diskusi dan transparan bagi semua karyawan yang tertarik. Tidak mungkin untuk melaporkan secara langsung bahwa Dari jam 8 pagi sampai jam 10, dan pada jam 16:00 perang dengan Inggris, penting untuk melihat seluruh rencana dalam perspektif.

Rencana tersebut harus mencerminkan persyaratan karyawan yang akan menjadi pengguna akhir - sehingga setiap karyawan akan mengetahui dengan tepat fitur apa yang diinginkan dan kapan ia dapat menggunakannya. Pada saat yang sama, rencana transisi atau implementasi bukanlah semacam monolit yang tidak berubah, perlu untuk meninggalkan kemungkinan menyelesaikan rencana dan mengubah atributnya (tetapi tidak dalam bentuk aliran pengeditan tanpa akhir dan "Daftar Keinginan" baru dan tidak dalam bentuk pergeseran istilah yang konstan).

Apa yang seharusnya ada dalam rencana?

1. Tonggak sejarah transisi (tahapan) - apa yang perlu dilakukan.
   
2. Poin transisi terperinci untuk setiap tahap - bagaimana hal itu harus dilakukan.
   
3. Poin-poin penting dan melaporkannya (rekonsiliasi jam) - bagaimana mengukur apa yang telah dilakukan dan siapa yang harus berada di titik kontrol.
   
4. Mereka yang bertanggung jawab adalah orang yang dapat dihubungi dan yang dapat ditanyakan.
   
5. Tanggal - awal dan akhir setiap tahap dan seluruh proses.
   
6. Proses yang terpengaruh - perubahan apa yang akan terjadi dalam proses bisnis, apa yang perlu diubah seiring dengan implementasi / transisi.
   
7. Penilaian akhir - serangkaian indikator, metrik atau bahkan penilaian subjektif yang akan membantu menilai implementasi / transisi.
   
8. Mulai operasi adalah waktu yang tepat ketika seluruh perusahaan akan bergabung dengan proses otomatis yang diperbarui dan akan bekerja dalam sistem baru.
   

Kami bertemu dengan presentasi pelaksana, di mana garis merah adalah saran: untuk memperkenalkan kekuatan, mengabaikan reaksi, jangan berbicara dengan karyawan. Kami menentang pendekatan ini, dan inilah alasannya.

Lihatlah gambar di bawah ini:



Mouse baru, keyboard baru, apartemen, mobil, dan bahkan pekerjaan adalah peristiwa yang menyenangkan dan menyenangkan, beberapa di antaranya bahkan merupakan prestasi. Dan pengguna pergi ke Yandex untuk mencari tahu bagaimana membiasakan diri, beradaptasi. Cara memasuki apartemen baru dan memahami bahwa itu adalah milik Anda, pertama buka keran, minum teh, pergi tidur untuk pertama kalinya. Cara mendapatkan di belakang kemudi dan berteman dengan mobil baru, milikmu, tapi sejauh ini sangat asing. Perangkat lunak baru di tempat kerja tidak berbeda dari situasi yang dijelaskan: pekerjaan karyawan tidak akan pernah sama. Oleh karena itu, terapkan, beradaptasi, tumbuh dengan perangkat lunak baru yang efektif. Dan inilah situasi yang bisa kita katakan: cepatlah.