Seri transformasi digital: Mile terakhir

Jika Anda membaca posting ini, Anda mungkin belum berada di mil terakhir dari proyek transformasi Anda.

Seringkali, beberapa bulan terakhir dari sebuah proyek transformasi sangat intens sampai-sampai dihabiskan sepenuhnya—tidak peduli seberapa bagus perencanaan proyek Anda, komunikasi Anda, dan pengorganisasian tim Anda. Ini hanya karena transformasi digital sering kali berdampak pada struktur perusahaan yang sangat besar—bahkan mungkin dampak terbesar yang pernah dialami perusahaan.

Dalam banyak kasus, transformasi digital menyentuh lebih banyak elemen teknis, bisnis, dan organisasi perusahaan daripada sebelumnya.

Mengingat dampak itu, mudah bagi perusahaan untuk bergeming—kurangi cakupan sebagian, tahap peluncuran untuk mengurangi dampak, tingkatkan pengawasan, dan dengan demikian memperlambat proyek. Biasanya, pendekatan ini—reaksi spontan ini—adalah sebuah kesalahan. Saya telah mengatakan di posting sebelumnya, transformasi digital adalah pengalaman yang sulit untuk mengubah perusahaan. Memiliki seluruh perusahaan di belakang perubahan—dari atas ke bawah—akan menentukan tingkat keberhasilan proyek pada akhirnya. Jangan bergeming! Ada beberapa langkah yang dapat Anda ambil di mil terakhir proyek untuk memaksimalkan dampak dan nilai transformasi Anda terhadap bisnis.

Banyak gangguan yang dapat datang selama fase akhir peluncuran Anda dapat dikurangi jika pernyataan misi dan komunikasi proyek Anda telah dikelola dengan baik– dan disampaikan terhadap– di awal proyek.

Fase terakhir adalah tempat yang benar-benar salah untuk memperdebatkan nilai yang dapat diberikan oleh proyek saat ini. Hal termudah untuk dilakukan adalah mengarahkan mereka yang membuat kebisingan kembali ke Misi asli yang didukung eksekutif untuk proyek tersebut. Meskipun demikian, sering kali ada pemain baru yang muncul—terutama ketika menjadi jelas tingkat gangguan yang mungkin dimiliki oleh transformasi tersebut.

Pernyataan misi dan dukungan eksekutif dapat memiliki dampak menenangkan yang besar bagi pemain baru, dan berbagi komunikasi sebelumnya dengan mereka juga dapat membantu mereka menerima dan merasa lebih sebagai bagian dari proses.

Hal ini sering terjadi selama tahap akhir dari sebuah proyek bahwa jadwal berada di bawah tekanan dan Anda akan mencari cara untuk memadatkan jadwal. Anda harus sangat berhati-hati di sini.

Ada empat area dalam proyek yang sering dikompromikan – yang sangat merugikan keberhasilan proyek.

Proyek transformasi digital: Pengujian

Transformasi digital sering kali dikelola di luar TI. Pengujian mungkin dimulai sebagai kombinasi pengujian penerimaan teknis dan bisnis, tetapi di bawah tekanan pengiriman, ini tampak besar sebagai target. Biasanya ingin mengompresi siklus pengujian proyek. Salah satu tempat pertama yang mungkin terlihat oleh tim proyek dalam garis kapur proyek adalah pengujian penerimaan pengguna bisnis. Ini adalah area yang sangat berbahaya untuk dipotong.

Melibatkan pengguna bisnis dalam menerima dan mengomentari perangkat lunak adalah bagian penting dari proyek dan butuh waktu untuk melewati siklus ini. Ini mungkin tidak terasa seperti tingkat ketelitian yang sama yang diterapkan pada pengujian sistem dan unit, tetapi setidaknya sama pentingnya. Memotong di sini untuk menghemat garis waktu dapat mengakibatkan upaya pengerjaan ulang yang besar karena pengguna menolak mentah-mentah atau menantang apa yang dibuat. Ini memiliki dampak waktu tetapi juga dapat merusak momentum dan dukungan untuk keberhasilan proyek. Buat pengguna bisnis tetap terlibat dan dorong mereka ke respons tepat waktu sebaik mungkin. Kursus lain apa pun yang mengurangi pengujian pengguna meningkatkan risiko Anda berlipat ganda.

Fase integrasi

Menyebarkan perangkat lunak baru tidak terjadi dalam ruang hampa. Selalu ada sistem lain untuk terhubung. Salah satu kesalahan yang lebih umum dalam proyek transformasi adalah mengasumsikan bahwa integrasi ke sistem warisan ini akan bekerja dengan cara yang sama seperti di masa lalu. Dalam hampir semua kasus, itu akan menjadi asumsi yang buruk.

Saya baru-baru ini bekerja dengan pelanggan yang mengidentifikasi lebih dari 50 integrasi yang harus dikirimkan untuk go-live terakhir. Bekerja dengan tim layanan ahli kami, mereka dapat melalui, satu per satu, mengidentifikasi apa yang penting untuk proyek dan apa yang bisa ditunda.

Karena validasi integrasi Anda tidak dapat dilakukan hingga akhir proyek, ada kecenderungan alami untuk mempercepat bagian integrasi. Ini adalah hal yang cukup berbahaya untuk dilakukan—kami sering melihat kegagalan integrasi sebagai tantangan besar pada menit terakhir untuk transformasi. Meluangkan waktu untuk mengidentifikasi integrasi mana yang waktu nyata, yang mendekati waktu nyata, dan yang dapat didorong ke batch dapat membantu mengatasi tantangan integrasi.

Seringkali, kami menemukan bahwa integrasi yang diidentifikasi membutuhkan panggilan real-time paling 'mahal' ternyata kurang penting—dan dapat menerapkan strategi hampir real-time. Contoh klasik—apakah Anda benar-benar membutuhkan validasi inventaris waktu nyata saat seseorang melihat detail item dalam katalog? Apakah Anda bahkan memerlukan validasi waktu nyata jika ditambahkan ke keranjang belanja? Dalam banyak kasus bisnis, satu-satunya panggilan inventaris waktu nyata terjadi saat keranjang dikonfirmasi untuk checkout.

Semakin banyak Anda dapat mendokumentasikan dan memvalidasi masalah integrasi SEBELUM mencapai mil terakhir, semakin besar kemungkinan Anda akan selamat dari tes ini. Integrasi sistem lama yang dibangun selama bertahun-tahun sering kali tidak bekerja dengan cara yang sama saat terhubung ke sistem baru. Menggali lebih awal hanya dapat membantu Anda dalam upaya kunci ini. Ini adalah area di mana membuat asumsi tanpa validasi akan kembali menimbulkan tantangan besar bagi Anda.

Uji beban

Terkait erat dengan upaya Integrasi adalah pengujian beban. Terlalu sering, pelanggan membuat asumsi tentang beban berdasarkan kinerja stok perangkat lunak vendor. Ini adalah penalaran yang salah. Anda menyesuaikan dan menyesuaikan solusi dengan kebutuhan spesifik Anda. Setiap pengaturan yang diubah dan setiap alur kerja khusus membuat Anda selangkah lebih jauh dari tolok ukur apa pun yang disediakan vendor untuk throughput. Terlebih lagi, integrasi Anda akan berdampak besar pada kinerja solusi Anda—dan vendor Anda tidak dapat mengantisipasi dampak apa yang akan terjadi.

Anda harus memiliki keterlibatan vendor tertentu untuk meninjau arsitektur, pengaturan, integrasi, dan pekerjaan kustom Anda sebagai bagian dari validasi kinerja. Gagal melakukan ini dapat mengakibatkan masalah besar dengan siaran langsung Anda. Baru-baru ini ada pelanggan yang menghubungi saya setelah meluncurkan empat dari rencana peluncuran 40 negara mereka—yang terbesar dari keempatnya adalah Irlandia. Mereka mengalami masalah skala besar. Setelah keterlibatan darurat dengan tim kinerja kami, menjadi jelas bahwa refactoring solusi yang substansial akan diperlukan. Peluncuran tambahan harus ditunda hingga sistem lulus uji beban—yang mengakibatkan rasa malu tim eksekutif yang dapat dihindari bagi CIO.

Saya telah menekankan sebelumnya bahwa pengujian beban sistem perlu menjadi bagian mendasar dari proyek Anda. Hilang, atau kurang mewakili langkah ini hampir selalu berakibat buruk.

Pelatihan

Ketika proyek berada di bawah tekanan waktu/pengiriman, salah satu hal pertama yang dilihat perusahaan adalah komponen pelatihan. Pemotongan di sini tampaknya sering menjadi cara mudah lain untuk mengurangi dampak pada tantangan ketepatan waktu pengiriman proyek. Jangan lakukan itu!

Pelatihan sering kali kurang terwakili untuk memulai proyek transformasi digital. Tidak ada yang lebih buruk daripada memiliki sistem baru yang gagal karena tidak ada yang bisa menggunakannya. Ini seringkali bukan masalah teknologi. Orang membuat sistem berfungsi—atau tidak. Orang-orang itu harus tahu dan membeli apa yang akan mereka gunakan.

Pelatihan secara kasar terbagi menjadi dua komponen utama—jangan abaikan salah satu dari keduanya.

Pelatihan sistem: Ini adalah pelatihan untuk tim yang akan mengelola alur kerja dan proses bisnis yang telah Anda rancang dalam proyek. Di sinilah sebagian besar fokus pelatihan pergi. Memastikan bahwa orang tahu mengapa dan bagaimana sistem diluncurkan, dan bagaimana pekerjaan mereka akan berubah sangat penting untuk upaya terakhir. Ada cukup banyak pekerjaan di sini jika Anda secara substansial mengubah proses bisnis yang telah ada sejak lama. Pastikan tim tahu apa yang mereka lakukan dan mengapa!

Ini adalah kesempatan untuk membangun kegembiraan untuk solusi baru, dan membuat tim-tim ini bergabung akan memperlancar hambatan tak terhindarkan yang akan Anda alami dalam peluncuran. Pelatihan ini harus terdiri dari tiga aspek: Pelatihan vendor di ruang kelas atau di tempat, amandemen System Integrator untuk setiap keunikan yang dibuat untuk bisnis Anda, dan pengalaman langsung di kotak pasir di mana pengguna dapat membuat kesalahan di lingkungan yang aman. Tolong—apa pun yang Anda lakukan, jangan berasumsi bahwa pengguna hanya akan menerima apa yang Anda berikan kepada mereka. Ini bukan pendekatan yang bagus untuk membangun momentum yang Anda perlukan untuk mengklaim kesuksesan dalam transformasi digital…buatlah rencana pelatihan yang tepat, dan jangan mengambil jalan pintas. Kirim orang ke pelatihan dan libatkan mereka dalam upaya itu—itu akan membuahkan hasil.

Pelatihan pengguna akhir: Ini adalah area lain yang sering kurang tersampaikan dalam peluncuran transformasi digital. Hal terbaik yang dapat Anda lakukan adalah berkomunikasi dengan sampel pengguna akhir tentang apa yang akan datang, melihat berapa lama waktu yang dibutuhkan bagi mereka untuk memahami dan membuat rencana pelatihan Anda sesuai dengan itu. Sering kali, perusahaan suka memasukkan sekelompok pengguna akhir sebagai 'juara' untuk solusi tersebut. Ini dapat bekerja dengan baik untuk 'menyemai' komunitas pengguna dengan tim yang sudah memahami sistem.

Mil terakhir selalu di mana krisis datang. Tetapi langkah-langkah di atas akan membantu Anda menghadapi tantangan dengan tenang.