Pilot 30 Hari atau Implementasi Sekaligus? Cara Memilih Software Logistik Tanpa Bertaruh

Setiap demo software logistik berjalan mulus. Datanya bersih, alurnya lurus, dan orang yang mengoperasikan sudah melakukannya ratusan kali. Ini bukan penipuan. Demo memang dirancang begitu, dan vendor mana pun akan melakukan hal yang sama.

Persoalannya, demo yang selalu berhasil tidak memberi Anda informasi. Sesuatu yang hasilnya sudah pasti sebelum dijalankan tidak bisa dipakai untuk membedakan pilihan yang baik dari pilihan yang buruk.

Dasar pertama: uji yang berguna adalah uji yang bisa gagal

Karl Popper, dalam pembahasannya tentang metode ilmiah, mengajukan gagasan bahwa yang membedakan klaim yang bermakna dari klaim kosong adalah kemungkinan untuk dibantah. Teori yang cocok dengan semua kemungkinan hasil tidak menjelaskan apa apa, justru karena tidak ada hasil yang bisa membuktikannya salah.

Prinsip yang sama berlaku untuk pilot software. Kalau tidak ada satu pun hasil yang akan membuat Anda membatalkan pembelian, maka pilot itu bukan pengujian. Ia hanya pelatihan berbayar yang keputusannya sudah diambil sejak awal.

Dasar kedua: membeli bertahap adalah membeli hak untuk berubah pikiran

Dalam keuangan, sebuah opsi adalah hak untuk melakukan sesuatu tanpa kewajiban melakukannya. Opsi punya nilai, dan nilainya naik seiring besarnya ketidakpastian. Gagasan ini kemudian dipakai untuk menilai keputusan investasi nyata, bukan cuma instrumen keuangan, dan dikenal sebagai teori opsi riil.

Penerapannya di sini cukup langsung. Implementasi sekaligus mengunci seluruh komitmen di titik ketika pengetahuan Anda paling sedikit. Implementasi bertahap membagi komitmen itu, sehingga sebagian keputusan diambil setelah Anda tahu lebih banyak.

Perhatikan baris terakhir. Implementasi sekaligus bukan pilihan yang salah secara mutlak. Ia masuk akal ketika ketidakpastiannya rendah, misalnya saat Anda mengganti sistem lama dengan proses yang sudah berjalan bertahun tahun tanpa perdebatan. Ketika masih banyak yang belum diketahui, nilai opsi untuk berhenti menjadi tinggi, dan itulah yang dibeli oleh pendekatan bertahap.

Merancang pilot yang menghasilkan jawaban

Pilih proses tersibuk, bukan yang paling rapi

Godaan alaminya adalah menguji pada satu cabang kecil yang tenang, dengan tim yang paling kooperatif. Hasilnya akan bagus, dan hasil itu tidak memberi tahu apa apa tentang bagaimana sistem berperilaku saat volume naik.

Kalau tujuan pilot adalah mencari titik patah, jalankan di tempat yang paling mungkin mematahkannya. Cabang tersibuk, rute paling rumit, customer yang paling banyak menuntut. Kalau bertahan di sana, sisanya lebih mudah. Kalau patah, Anda baru saja mengetahuinya dengan biaya satu bulan, bukan satu tahun.

Tetapkan angka sebelum mulai

Pilot tanpa garis dasar akan dinilai berdasarkan kesan, dan kesan selalu dimenangkan oleh suara yang paling keras. Sebelum hari pertama, catat angka yang relevan dengan masalah yang hendak diselesaikan. Beberapa yang biasanya berguna:

• Waktu rata rata POD kembali ke kantor
• Hari dari job selesai sampai invoice terbit
• Jumlah pertanyaan status yang masuk per minggu
• Waktu respons RFQ pada persentil 90
• Jumlah selisih data antara operasional dan finance per bulan

Ambil dua sampai tiga saja, yang paling dekat dengan alasan Anda mencari sistem. Mengukur sepuluh hal sekaligus terdengar teliti, tapi dalam praktiknya tidak ada yang sempat mengumpulkannya, dan pilot berakhir tanpa data sama sekali.

Batasi durasi, dan tepati

Tiga puluh hari cukup untuk melewati satu siklus penagihan penuh dan menemui sebagian besar pengecualian yang nyata. Yang penting bukan angka tiga puluhnya, melainkan adanya tanggal berakhir yang tidak bergeser.

Pilot yang diperpanjang berulang kali biasanya bukan pilot yang butuh waktu lebih. Ia pilot yang tidak ada yang berani menyimpulkan hasilnya.

Jebakan yang paling sulit dihindari: biaya yang sudah terlanjur keluar

Dalam ilmu ekonomi ada prinsip yang mudah dipahami tapi sulit dijalankan: biaya yang sudah dikeluarkan dan tidak bisa ditarik kembali seharusnya tidak memengaruhi keputusan selanjutnya. Yang relevan hanyalah biaya dan manfaat ke depan.

Dalam praktik proyek, prinsip ini nyaris selalu dilanggar. Setelah mengeluarkan uang dan tenaga besar, menghentikan proyek terasa seperti mengakui kesalahan, sehingga argumen yang muncul berbunyi seperti ini: kita sudah investasi banyak, sayang kalau berhenti sekarang.

“Uang yang sudah keluar tidak bisa dibuat berguna dengan cara mengeluarkan lebih banyak lagi.”

Cara paling efektif melawannya adalah menuliskan kriteria berhenti sebelum uang pertama keluar, lalu menyerahkan penilaiannya kepada orang yang tidak ikut memutuskan pembelian. Orang yang mengusulkan proyek adalah orang yang paling sulit menilai proyeknya sendiri, dan itu bukan soal integritas, melainkan soal bagaimana manusia bekerja.

Pertanyaan ke vendor yang jawabannya benar benar membedakan

Sebagian besar pertanyaan dalam proses pengadaan dijawab sama oleh semua vendor, sehingga tidak membantu memilih. Yang berikut ini cenderung menghasilkan jawaban yang berbeda beda, dan perbedaannya bermakna:

1. 1Kalau kami berhenti berlangganan, dalam format apa data kami bisa dibawa keluar, dan berapa lama prosesnya? Jawaban yang mengambang di sini adalah tanda paling awal dari ketergantungan yang sulit dilepas.
2. 2Siapa yang menangani kami setelah masa implementasi selesai, dan berapa lama biasanya sebuah pertanyaan dijawab?
3. 3Tunjukkan satu implementasi yang tidak berjalan mulus, dan apa yang Anda ubah setelahnya. Vendor yang mengaku belum pernah gagal sedang mengatakan sesuatu tentang jumlah pelanggannya, atau tentang kejujurannya.
4. 4Berapa biaya total di tahun kedua dan ketiga, termasuk penambahan pengguna dan modul? Biaya tahun pertama sering disubsidi dan menyesatkan.
5. 5Apa yang tidak bisa dilakukan produk Anda? Jawaban jujur di sini adalah tanda kualitas yang paling baik yang bisa Anda dapatkan dalam proses pengadaan.

Menyimpulkan pilot: tiga kemungkinan, bukan dua

Kebanyakan orang menyiapkan diri untuk dua hasil, berhasil atau gagal. Dalam praktiknya hampir selalu muncul hasil ketiga, dan hasil ketiga inilah yang paling sering salah ditangani.

• Berhasil sesuai kriteria. Lanjutkan ke tahap berikutnya, dan tetapkan kriteria baru untuk tahap itu.
• Gagal sesuai kriteria. Hentikan. Biaya yang sudah keluar adalah harga dari informasi yang baru saja Anda peroleh, dan informasi itu murah dibanding komitmen penuh yang berhasil dihindari.
• Tidak jelas, karena datanya tidak terkumpul atau tim tidak sempat memakai. Ini bukan hasil netral. Ini kegagalan pada rancangan pilotnya, dan menjalankannya lagi dengan cara yang sama akan menghasilkan ketidakjelasan yang sama.

Kemungkinan ketiga adalah yang paling sering terjadi, dan paling sering ditafsirkan sebagai hasil yang cukup baik untuk melanjutkan. Padahal ia memberi tahu Anda satu hal yang penting: pada kondisi kerja yang sesungguhnya, tim tidak punya kapasitas untuk mengadopsi sistem sambil menjalankan operasional. Masalah itu tidak akan hilang dengan sendirinya pada tahap berikutnya, yang cakupannya lebih besar.