Karyawan tidak menginginkan perangkat lunak baru - haruskah mereka mengikuti petunjuk atau tetap berpegang pada jalurnya?

Lompatan perangkat lunak akan segera menjadi penyakit yang sangat umum di perusahaan. Mengubah satu perangkat lunak ke perangkat lunak lainnya karena segala hal, beralih dari teknologi ke teknologi, bereksperimen dengan bisnis langsung menjadi hal yang biasa. Pada saat yang sama, perang saudara yang sesungguhnya dimulai di kantor: gerakan perlawanan terhadap implementasi terbentuk, para partisan melakukan pekerjaan subversif melawan sistem baru, mata-mata mempromosikan dunia baru yang berani dengan perangkat lunak baru, manajemen dari mobil lapis baja. portal perusahaan menyiarkan tentang perdamaian, perburuhan, KPI. Sebuah revolusi biasanya berakhir dengan kegagalan total di satu sisi.

Kita mengetahui hampir segalanya tentang implementasi, jadi mari kita coba mencari cara untuk mengubah revolusi menjadi sebuah evolusi dan menjadikan implementasi berguna dan semudah mungkin. Ya, atau setidaknya kami akan memberi tahu Anda apa yang mungkin Anda hadapi dalam proses tersebut.

Visualisasi ideal penerimaan karyawan terhadap perangkat lunak baru Sumber - Yandex.Images

Konsultan asing akan memulai artikel ini seperti ini: “Jika Anda menawarkan perangkat lunak berkualitas kepada karyawan Anda yang dapat meningkatkan pekerjaan mereka, memiliki dampak kualitatif terhadap kinerja, penerapan program atau sistem baru akan terjadi secara alami.” Namun kami berada di Rusia, jadi masalah karyawan yang mencurigakan dan suka berperang sangatlah relevan. Transisi alami tidak akan berhasil, bahkan dengan perangkat lunak minimal seperti messenger perusahaan atau softphone.

Dari mana sumber permasalahannya?

Saat ini, setiap perusahaan mempunyai banyak sekali perangkat lunak yang terinstal (kami mengambil kasus umum, karena di perusahaan TI jumlah perangkat lunaknya dua atau tiga kali lipat, dan masalah adaptasi sebagian tumpang tindih dan sangat spesifik): sistem manajemen proyek, CRM/ERP, klien email, pesan instan, portal perusahaan, dll. Dan ini belum termasuk fakta bahwa ada perusahaan yang bahkan transisi dari browser ke browser dilakukan oleh seluruh tim tanpa kecuali (dan ada juga tim yang sepenuhnya berbasis Internet Explorer Edge). Secara umum, ada beberapa situasi yang mungkin berguna bagi artikel kami:

• Ada proses otomatisasi utama dari beberapa kelompok tugas: CRM/ERP pertama sedang diterapkan, portal perusahaan sedang dibuka, sistem dukungan teknis sedang dipasang, dll.;
• satu perangkat lunak digantikan oleh perangkat lunak lain karena alasan tertentu: keusangan, persyaratan baru, penskalaan, perubahan aktivitas, dll.;
• modul dari sistem yang ada sedang dibangun untuk tujuan pengembangan dan pertumbuhan (misalnya, sebuah perusahaan membuka produksi dan memutuskan untuk beralih dari RegionSoft CRM Profesional pada RegionSoft CRM Perusahaan Plus dengan fungsionalitas maksimal);
• Antarmuka utama dan pembaruan perangkat lunak fungsional sedang berlangsung.

Tentu saja, dua kasus pertama jauh lebih akut dan khas dalam manifestasinya, berikan perhatian khusus pada kasus tersebut.

Jadi, sebelum Anda mulai bekerja dengan tim (yang sudah menduga akan ada perubahan dalam waktu dekat), cobalah memahami apa alasan sebenarnya untuk mengubah perangkat lunak dan apakah Anda setuju bahwa perubahan tersebut sangat diperlukan.

• Program lama sulit untuk digunakan: mahal, tidak nyaman, tidak berfungsi, tidak lagi memenuhi kebutuhan Anda, tidak sesuai untuk skala Anda, dll. Ini adalah kebutuhan obyektif.
• Vendor berhenti mendukung sistem, atau dukungan dan modifikasi berubah menjadi serangkaian persetujuan dan pengurasan uang tanpa akhir. Jika biaya Anda meningkat secara signifikan, dan di masa depan mereka berjanji akan meningkat lebih banyak lagi, tidak ada yang perlu ditunggu, Anda perlu menguranginya. Ya, sistem baru juga memerlukan biaya, tetapi pada akhirnya optimasi akan memakan biaya lebih murah dibandingkan dukungan tersebut.
• Mengubah perangkat lunak adalah keinginan seseorang atau sekelompok karyawan. Misalnya, CTO menginginkan kemunduran dan melobi untuk memperkenalkan sistem baru yang lebih mahal - hal ini terjadi di perusahaan besar. Contoh lain: manajer proyek menganjurkan perubahan Asana menjadi Basecamp, lalu Basecamp menjadi Jira, dan kompleks Jira menjadi Wrike. Seringkali satu-satunya motif migrasi tersebut adalah untuk memamerkan kesibukan mereka dan mempertahankan posisi mereka. Dalam kasus seperti itu, perlu untuk menentukan tingkat kebutuhan, motif dan pembenaran dan, sebagai suatu peraturan, dengan keputusan yang berkemauan keras untuk menolak perubahan.

Kita berbicara tentang alasan transisi dari satu perangkat lunak ke perangkat lunak lainnya, dan bukan tentang otomatisasi primer - hanya karena otomatisasi secara apriori diperlukan. Jika perusahaan Anda melakukan sesuatu secara manual dan rutin tetapi dapat dilakukan secara otomatis, Anda hanya membuang-buang waktu, uang, dan, kemungkinan besar, data perusahaan yang berharga. Otomatiskan!

Bagaimana Anda bisa menyeberang: lompatan besar atau harimau yang berjongkok?

Dalam praktik dunia, ada tiga strategi utama untuk beralih ke perangkat lunak baru dan beradaptasi dengannya - dan strategi tersebut tampaknya sangat cocok bagi kita, jadi jangan kita ubah arah.

Big Bang

Adopsi menggunakan metode “Big Bang” adalah transisi yang paling sulit, ketika Anda menetapkan tanggal pasti dan melakukan migrasi mendadak, menonaktifkan perangkat lunak lama 100%.

Kelebihan:

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

Kontra

— Bekerja dengan sukses hanya dengan perangkat lunak sederhana: obrolan, portal perusahaan, pesan instan. Bahkan email pun sudah bisa gagal, belum lagi sistem manajemen proyek, CRM/ERP dan sistem serius lainnya.
— Migrasi eksplosif dari satu sistem besar ke sistem lain pasti akan menyebabkan kekacauan.

Hal terpenting untuk transisi ke lingkungan kerja baru ini adalah pelatihan.

Berjalan Paralel

Adaptasi paralel terhadap perangkat lunak adalah metode transisi yang lebih lembut dan universal, di mana periode waktu ditetapkan di mana kedua sistem akan berfungsi secara bersamaan.

Kelebihan:

+ Pengguna memiliki cukup waktu untuk membiasakan diri dengan perangkat lunak baru sambil segera mengerjakan perangkat lunak lama, menemukan persamaan, dan memahami logika interaksi baru dengan antarmuka.
+ Jika terjadi masalah mendadak, karyawan tetap bekerja di sistem lama.
+ Pelatihan pengguna tidak terlalu ketat dan umumnya lebih murah.
+ Praktis tidak ada reaksi negatif dari karyawan - lagipula, mereka tidak kehilangan alat atau cara melakukan sesuatu (jika otomatisasi terjadi untuk pertama kalinya).

Kontra

— Masalah administrasi: dukungan kedua sistem, sinkronisasi data, manajemen keamanan pada dua aplikasi sekaligus.
— Proses transisi berlangsung tanpa henti - karyawan menyadari bahwa mereka memiliki waktu yang sangat lama, dan mereka dapat lebih memperluas penggunaan antarmuka yang sudah dikenal.
- Kebingungan Pengguna - Kedua antarmuka membingungkan dan menyebabkan kesalahan operasional dan data.
- Uang. Anda membayar untuk kedua sistem.

Adopsi Bertahap

Adaptasi langkah demi langkah adalah pilihan paling lembut untuk beralih ke perangkat lunak baru. Transisi dilakukan secara fungsional, dalam jangka waktu tertentu dan berdasarkan departemen (misalnya, mulai 1 Juni kami menambahkan klien baru hanya ke sistem CRM baru, mulai 20 Juni kami melakukan transaksi di sistem baru, hingga 1 Agustus kami mentransfer kalender dan kasusnya, dan pada tanggal 30 September kami menyelesaikan migrasi yang merupakan gambaran yang sangat kasar, tetapi secara umum jelas).

Kelebihan:

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

Kontra - kira-kira sama dengan transisi paralel.

Jadi sekarang, transisi bertahap saja?

Sebuah pertanyaan logis, Anda pasti setuju. Mengapa harus repot jika Anda bisa membuat jadwal dan bertindak berdasarkan rencana yang jelas? Faktanya, tidak semuanya sesederhana itu.

• 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 model yang cocok adalah ketika Anda mengumumkan tanggal dan menonaktifkan perangkat lunak lama pada hari yang ditentukan (jika Anda beruntung, karyawan akan memiliki waktu untuk mengeluarkan semua informasi yang mereka butuhkan , dan jika Anda tidak mengandalkan keberuntungan, maka Anda perlu menyediakan impor otomatis data yang diperlukan dari sistem lama ke sistem baru, jika memungkinkan secara teknis).
• Tingkat risiko bagi perusahaan: semakin berisiko penerapannya, seharusnya semakin lambat pelaksanaannya. Di sisi lain, penundaan juga merupakan risiko: misalnya, Anda berpindah dari satu sistem CRM ke sistem CRM lainnya, dan selama masa transisi Anda terpaksa membayar keduanya, sehingga meningkatkan biaya dan biaya penerapan sistem baru, yang mana berarti periode pengembalian diperpanjang.
• Jumlah karyawan: Big Bang jelas tidak cocok jika Anda perlu menskalakan dan mengonfigurasi banyak profil pengguna. Meskipun ada kalanya implementasi ultra-cepat bermanfaat bagi perusahaan besar. Opsi ini mungkin cocok untuk sistem yang digunakan oleh banyak karyawan, namun mungkin tidak memiliki persyaratan karena penyesuaian tidak dimaksudkan. Namun sekali lagi, ini merupakan terobosan besar bagi pengguna akhir dan pekerjaan langkah demi langkah yang besar untuk layanan TI yang sama (misalnya, sistem penagihan atau akses).
• Fitur implementasi perangkat lunak yang dipilih (revisi, dll). Terkadang penerapannya pada awalnya tahap demi tahap - dengan pengumpulan persyaratan, penyempurnaan, pelatihan, dll. Misalnya, sistem CRM itu selalu diimplementasikan secara progresif dan jika seseorang menjanjikan Anda "implementasi dan konfigurasi dalam 3 hari atau bahkan 3 jam" - ingat artikel ini dan lewati layanan tersebut: instalasi ≠ implementasi.

Sekali lagi, meskipun mengetahui parameter yang tercantum, seseorang tidak dapat secara pasti mengambil satu jalur atau lainnya. Menilai lingkungan perusahaan Anda - ini akan membantu Anda memahami keseimbangan kekuatan dan menentukan model mana (atau kombinasi beberapa elemennya) yang tepat untuk Anda.

Agen pengaruh: revolusi atau evolusi

Hal pertama yang harus Anda perhatikan adalah karyawan yang akan terkena dampak implementasi perangkat lunak baru. Sebenarnya permasalahan yang kami pertimbangkan saat ini adalah murni faktor manusia, sehingga analisa dampaknya terhadap karyawan tidak bisa dihindari. Kami telah menyebutkan beberapa di antaranya di atas.

• Pimpinan perusahaan menentukan bagaimana perangkat lunak baru akan diterima secara umum. Dan ini bukan tempat untuk pidato promosi dan pidato yang berapi-api - penting untuk menunjukkan dengan tepat perlunya perubahan, untuk menyampaikan gagasan bahwa ini hanyalah memilih alat yang lebih keren dan nyaman, sama seperti mengganti laptop lama. Kesalahan terbesar manajemen dalam situasi seperti ini adalah mencuci tangan dan menarik diri: jika manajemen tidak memerlukan otomatisasi perusahaan, mengapa hal itu harus menjadi perhatian karyawan? Berada dalam proses.
• Kepala departemen (manajer proyek) adalah penghubung perantara yang harus berpartisipasi dalam semua proses, mengelola ketidakpuasan, menunjukkan kemauan dan mengatasi setiap keberatan rekan kerja, dan melakukan pelatihan yang berkualitas tinggi dan mendalam.
• Layanan TI (atau administrator sistem) - pada pandangan pertama, ini adalah burung awal Anda, yang paling mudah beradaptasi dan adaptif, tapi... tidak. Seringkali, terutama di perusahaan kecil dan menengah, administrator sistem menentang segala perubahan (penguatan) infrastruktur TI, dan ini bukan karena alasan teknis, tetapi karena kemalasan dan keengganan untuk bekerja. Siapa di antara kita yang belum mencari cara untuk menghindari pekerjaan? Namun jangan sampai hal ini merugikan seluruh perusahaan.
• Pengguna akhir, pada umumnya, ingin bekerja dengan baik dan nyaman di satu sisi dan, seperti manusia lainnya, takut akan perubahan. Argumen utama mereka jujur ​​dan sederhana: mengapa kita memperkenalkan/mengubah, apa batas kendali, bagaimana pekerjaan akan dinilai, apa yang akan berubah dan apa risikonya (omong-omong, setiap orang harus mengevaluasi risikonya - padahal kami vendor sistem CRM, tapi kami tidak bermaksud mengatakan bahwa semuanya selalu berjalan lancar: ada risiko dalam proses apa pun dalam bisnis).
• “Otoritas” dalam perusahaan adalah partisan yang dapat mempengaruhi karyawan lain. Ini belum tentu orang dengan posisi tinggi atau pengalaman luas - dalam hal bekerja dengan perangkat lunak, “otoritas” mungkin adalah orang yang sangat tahu segalanya yang, misalnya, telah membaca ulang Habr dan akan mulai mengintimidasi semua orang tentang betapa buruknya segala sesuatunya. Dia bahkan mungkin tidak memiliki tujuan untuk merusak proses implementasi atau transisi - hanya pamer dan semangat perlawanan - dan karyawan akan mempercayainya. Anda perlu bekerja dengan karyawan seperti itu: menjelaskan, mempertanyakan, dan terutama dalam kasus-kasus sulit, memberi petunjuk tentang konsekuensinya.

Ada resep universal untuk memeriksa apakah pengguna benar-benar takut terhadap sesuatu atau apakah mereka mengalami paranoia kelompok yang dipimpin oleh pemimpin yang cerdas. Tanyakan kepada mereka tentang alasan ketidakpuasan, tentang kekhawatiran - jika ini bukan pengalaman atau pendapat pribadi, argumen akan mulai mengalir setelah 3-4 pertanyaan klarifikasi.

Dua faktor penting untuk keberhasilan mengatasi “gerakan perlawanan”.

1. Memberikan pelatihan: vendor dan internal. Pastikan karyawan benar-benar memahami segalanya, telah menguasainya dan, apapun tingkat pelatihannya, siap untuk mulai bekerja. Atribut wajib pelatihan adalah instruksi (peraturan) cetak dan elektronik serta dokumentasi terlengkap pada sistem (vendor yang menghargai diri sendiri merilisnya bersama dengan perangkat lunak dan menyediakannya secara gratis).
2. Cari pendukung dan pilih influencer. Pakar internal dan pengguna awal adalah sistem pendukung Anda, yang mendidik dan menghilangkan keraguan. Biasanya, karyawan sendiri dengan senang hati membantu rekan kerja mereka dan memperkenalkan mereka pada perangkat lunak baru. Tugas Anda adalah memberhentikan sementara mereka dari pekerjaan atau memberi mereka bonus yang layak untuk beban kerja baru mereka.

Apa yang perlu Anda perhatikan?

1. Seberapa majukah karyawan yang terkena dampak perubahan ini? (Secara relatif, jika besok mereka menciptakan program akuntansi baru, Tuhan melarang Anda menyodok departemen akuntansi dengan wanita berusia di atas 50 tahun dan menyarankan transisi dari 1C, Anda tidak akan keluar hidup-hidup).
2. Seberapa besar pengaruhnya terhadap alur kerja? Mengubah pembawa pesan di perusahaan yang beranggotakan 100 orang adalah satu hal, menerapkan sistem CRM baru yang didasarkan pada proses utama dalam perusahaan adalah satu hal (dan ini bukan hanya penjualan, misalnya, penerapan RegionSoft CRM di edisi senior hal ini mempengaruhi produksi, gudang, pemasaran, dan manajer puncak yang, bersama dengan tim, akan membangun proses bisnis otomatis).
3. Apakah pelatihan diberikan dan pada tingkat apa?

Satu-satunya transisi logis dalam sistem pemikiran perusahaan

Apa yang akan menyelamatkan transisi/implementasi perangkat lunak baru?

Sebelum kami memberi tahu Anda poin-poin penting apa yang akan membantu Anda berpindah dengan nyaman ke perangkat lunak baru, izinkan kami menarik perhatian Anda ke satu poin. Ada sesuatu yang pasti tidak boleh dilakukan - tidak perlu memberi tekanan pada karyawan dan “memotivasi” mereka dengan mencabut bonus, sanksi administratif dan disiplin. Hal ini tidak akan membuat proses menjadi lebih baik, namun sikap para karyawan akan memburuk: jika mereka memaksakan, maka akan ada kendali; Jika mereka memaksa Anda, itu berarti mereka tidak menghargai kepentingan kami; Jika mereka memaksakannya dengan paksa, berarti mereka tidak mempercayai kita dan pekerjaan kita. Oleh karena itu, kami melakukan segala sesuatunya dengan disiplin, jelas, kompeten, namun tanpa tekanan dan pemaksaan yang tidak perlu.

Anda harus memiliki rencana tindakan yang terperinci

Segala sesuatu yang lain mungkin tidak ada, tapi harus ada rencana. Selain itu, rencana tersebut dapat disesuaikan, diperbarui, jelas dan tidak dapat dihindari, sekaligus dapat diakses untuk didiskusikan dan transparan bagi semua karyawan yang berkepentingan. Tidak mungkin untuk mengkomunikasikan secara langsung bahwa dari jam 8 pagi sampai jam 10 pagi ada suatu prestasi, dan pada jam 16:00 ada perang dengan Inggris; penting untuk melihat keseluruhan rencana dalam perspektif.

Rencana tersebut harus mencerminkan kebutuhan karyawan yang akan menjadi pengguna akhir - dengan cara ini setiap karyawan akan mengetahui secara pasti fitur apa yang diinginkan dan pada jam berapa dia dapat menggunakannya. Pada saat yang sama, rencana transisi atau implementasi bukanlah sebuah monolit yang tidak dapat diubah; kita perlu meninggalkan kemungkinan untuk menyelesaikan rencana dan mengubah atribut-atributnya (tetapi tidak dalam bentuk aliran pengeditan dan “keinginan” baru yang tiada habisnya. dan bukan dalam bentuk perubahan tenggat waktu yang konstan).  

Apa yang harus ada dalam rencana itu?

1. Tonggak (tahapan) transisi utama - apa yang perlu dilakukan.
2. Poin transisi terperinci untuk setiap tahap - bagaimana hal itu harus dilakukan.
3. Poin-poin penting dan pelaporannya (rekonsiliasi jam kerja) - bagaimana apa yang telah dilakukan akan diukur dan siapa yang harus berada di titik kontrol.
4. Orang yang bertanggung jawab adalah orang yang dapat Anda hubungi dan ajukan pertanyaan.
5. Batas waktu adalah awal dan akhir dari setiap tahap dan keseluruhan proses secara keseluruhan.
6. Proses yang terkena dampak – perubahan apa yang akan terjadi dalam proses bisnis, apa yang perlu diubah seiring dengan implementasi/transisi.
7. Penilaian akhir merupakan seperangkat indikator, metrik atau bahkan penilaian subjektif yang akan membantu mengevaluasi implementasi/transisi yang telah terjadi.
8. Awal operasi adalah tanggal pasti ketika seluruh perusahaan akan bergabung dengan proses otomatis yang diperbarui dan bekerja dalam sistem baru.

Kami telah menjumpai presentasi para pelaksana yang garis merahnya adalah nasihat: terapkan dengan paksa, abaikan reaksinya, jangan bicara 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 menggembirakan, beberapa di antaranya bahkan merupakan pencapaian. Dan pengguna membuka Yandex untuk mencari tahu cara membiasakan diri dan beradaptasi. Bagaimana memasuki apartemen baru dan memahami bahwa itu milik Anda, menyalakan keran untuk pertama kalinya, minum teh, tidur untuk pertama kalinya. Bagaimana berada di belakang kemudi dan berteman dengan mobil baru, milik Anda, tetapi sejauh ini asing. Perangkat lunak baru di tempat kerja tidak berbeda dengan situasi yang dijelaskan: pekerjaan karyawan tidak akan pernah sama. Oleh karena itu, terapkan, adaptasi, kembangkan dengan perangkat lunak baru yang efektif. Dan inilah situasi yang bisa kita katakan: cepatlah perlahan.

Sumber: www.habr.com