Saya sudah cukup banyak mengikuti rapat anggaran untuk hafal polanya. Seseorang memberikan angka yang jelas untuk sebuah sistem baru, tim keuangan mengangguk, proyek berhasil dilaksanakan, dan delapan belas bulan kemudian terjadi percakapan yang canggung tentang mengapa pembelanjaan sebenarnya 40 persen lebih tinggi dari yang direncanakan. Jarang terjadi penipuan dan jarang terjadi ketidakmampuan. Kesalahan anggaranlah yang berulang, tahun demi tahun, bisnis demi bisnis, karena metode perencanaannya sendiri yang rusak.
Masalah intinya adalah sebagian besar anggaran TI dibuat untuk mendapatkan persetujuan, bukan untuk bertahan menghadapi kenyataan. Mereka memang optimis, karena angka yang jujur akan lebih sulit dijual dalam pertemuan tersebut. Hal ini berlaku hingga bulan Februari, ketika tagihan pertama untuk sesuatu yang tidak dianggarkan telah jatuh tempo.
Saya ingin menelusuri garis-garis spesifik yang hilang, dan memberi Anda struktur yang bertahan melewati kuartal pertama.
Tiga baris yang hilang
Hampir setiap anggaran TI yang rusak yang saya ulas tidak memiliki tiga hal yang sama.
Pemeliharaan dan dukungan. Sebuah sistem yang membutuhkan biaya pembangunan sebesar Rp 500 juta tidak memerlukan biaya nol untuk menjalankannya. Perbaikan bug, patch keamanan, hosting, permintaan fitur kecil, semuanya bertambah. Anggarkan 15 hingga 20 persen dari biaya pembangunan per tahun, setiap tahun, selama sistem masih berproduksi. Jika tidak ada yang menanyakan baris ini, berarti tidak ada yang menjalankan sistem pada tahun lalu.
Biaya integrasi. Sistem baru jarang berjalan sendiri. Itu perlu berhubungan dengan perangkat lunak akuntansi Anda, CRM Anda, tempat penjualan Anda, apa pun yang menjalankan bisnis. Pekerjaan integrasi hampir tidak pernah dimasukkan dalam penawaran asli karena vendor mencakup rangkaian fitur inti, bukan jalinan spesifik alat yang ada. Tambahkan fase penemuan khusus untuk integrasi harga sebelum Anda berkomitmen pada suatu angka.
Pelatihan dan manajemen perubahan. Perangkat lunak tidak akan menciptakan nilai sampai orang menggunakannya dengan benar. Saya telah menyaksikan jaringan ritel di Tangerang menggunakan sistem inventaris yang solid dan kemudian kehilangan sebagian besar keuntungan efisiensi yang diproyeksikan karena staf terus mengerjakannya, menggunakan proses manual lama secara paralel, selama berbulan-bulan. Tidak ada yang menganggarkan waktu atau uang untuk pelatihan, jadi tidak ada yang memilikinya.
Optimisme bukanlah metode perencanaan
Masalah yang lebih mendalam adalah bias yang tertanam dalam proses estimasi itu sendiri. Ketika vendor atau tim internal membuat garis waktu dan biaya awal, semua orang yang terlibat ingin jumlah tersebut terlihat dapat dicapai. Pembengkakan yang berlebihan dianggap sebagai kegagalan individu, sehingga orang-orang secara diam-diam memperkecil perkiraan mereka sendiri agar tidak terlihat seperti orang yang pesimis.
Solusinya bukanlah orang yang lebih baik. Ini pertanyaan yang berbeda. Daripada bertanya "berapa biayanya jika semuanya berjalan dengan baik", tanyakan "berapa sebenarnya biaya dari tiga proyek terakhir seperti ini, mulai hingga selesai, termasuk bagian-bagian yang jelek." Kalau belum punya sejarah itu, bangunlah sekarang juga, agar anggaran selanjutnya tidak main-main lagi.
Garis darurat yang bertahan di bulan Februari
Setiap anggaran TI harus memiliki kontinjensi sebesar 15 hingga 25 persen di atas perkiraan dasar. Itu bukanlah nasihat yang kontroversial. Yang kontroversial adalah apa yang sebenarnya terjadi.
Dalam praktiknya, garis darurat diperlakukan sebagai uang gratis ketika proyek menunjukkan adanya kelonggaran. Seorang pemangku kepentingan meminta satu fitur lagi, seseorang mengatakan "kami memiliki kemungkinan untuk itu," dan pada bulan Februari, penyangga tersebut hilang dan risiko sebenarnya bahkan belum terlihat.Lindungi dengan aturan: kontinjensi mencakup masalah yang tidak direncanakan, bukan penambahan ruang lingkup yang direncanakan. Jika seseorang menginginkan fitur baru, itu adalah permintaan perubahan dengan pembahasan anggarannya sendiri, bukan imbang terhadap margin keamanan. Aturan tunggal ini mencegah lebih banyak pembengkakan dibandingkan trik spreadsheet apa pun yang saya tahu.
Templat anggaran yang dapat menampung
Berikut struktur yang saya gunakan ketika menyusun anggaran TI yang dimaksudkan untuk bertahan sepanjang tahun:
| Item baris | Bagian tipikal dari total | Catatan |
|---|---|---|
| Pembuatan/lisensi inti | 40-50% | Nomor yang sudah dimiliki semua orang |
| Integrasi | 10-15% | Harga setelah penemuan lulus, tidak dapat ditebak |
| Pelatihan dan peluncuran | 5-10% | Waktu dan materi, bukan renungan |
| Pemeliharaan tahunan | 15-20% dari biaya pembangunan, berulang | Dianggarkan setiap tahun sistem berjalan |
| Kontingensi | 15-25% | Dicadangkan hanya untuk masalah yang tidak direncanakan |
Pemeliharaan pemberitahuan adalah satu-satunya garis yang dinyatakan sebagai persentase biaya pembangunan dan bukan total anggaran, karena hal ini berulang secara independen dari proyek aslinya. Masukkan ke dalam anggaran operasional Anda, bukan hanya anggaran proyek, atau anggaran tersebut akan hilang begitu saja setahun setelah diluncurkan.
Sebelum melakukan salah satu dari angka-angka ini, lakukan pemeriksaan pendahuluan yang sama dengan yang Anda lakukan pada proyek itu sendiri: apa satu atau dua alasan yang paling mungkin menyebabkan anggaran melebihi batas maksimumnya, dan apa hal termurah yang dapat Anda lakukan bulan ini untuk mencapainya lebih awal. Biasanya jawabannya adalah tinjauan bulanan aktual versus terencana, bukan alat baru.
Apa yang harus diperiksa sebelum Anda menyetujui yang berikutnya
Jika Anda meninjau anggaran TI sebelum disetujui, ajukan tiga pertanyaan dengan lantang di dalam ruangan: di mana jalur pemeliharaannya, di mana biaya integrasinya, dan apa yang terjadi pada kemungkinan jika tidak ada yang menyentuhnya. Jika ada jawaban yang tidak jelas, kirimkan kembali.
Bisnis yang mengalami kebangkrutan bukanlah bisnis yang menghabiskan terlalu banyak uang untuk TI. Merekalah yang menghabiskan jumlah yang tepat tetapi menyebutnya sebagai hal yang salah, kemudian menemukan jumlah sebenarnya pada tahun berikutnya. Anggaran yang menyebutkan titik lemahnya di awal akan bernilai lebih dari anggaran yang terlihat sempurna pada hari disetujui. Jika Anda memutuskan apakah akan membangun sistem sendiri atau membelinya, keputusan tersebut akan mengubah angka-angka ini secara substansial, jadi ada baiknya Anda memikirkannya sebelum anggaran disusun. Lihat Membangun vs Membeli Perangkat Lunak: Kerangka Keputusan untuk Pemilik untuk mengetahui dasar-dasarnya, dan jika anggaran terus gagal karena sistem yang mendasarinya sudah tua dan mahal untuk ditambal, perbaikan sebenarnya mungkin adalah menggantinya daripada menganggarkannya, yang tercakup dalam Biaya Tersembunyi Sistem Warisan dalam Bisnis Anda.