Perencanaan anggaran IT tahunan biasanya dimulai dari wish list dan berakhir dengan angka yang tidak bisa dipertanggungjawabkan siapa pun di bulan Maret. Cara yang lebih baik untuk menyusun anggaran teknologi tahun depan adalah berhenti menebak dan mulai dari apa yang benar-benar sudah dikeluarkan tahun ini, lalu menyesuaikannya secara sengaja, pos per pos, alih-alih memilih angka bulat dan berharap itu cukup.
Saya menyusun anggaran ini untuk praktik konsultasi saya sendiri setiap tahun, dan saya juga pernah duduk bersama pemilik bisnis yang menyusunnya untuk pertama kali. Polanya selalu sama: realisasi sebagai batas bawah, maintenance didanai sebelum hal baru apa pun, dan batas tegas untuk belanja eksperimental yang tidak terikat pada hasil yang terukur.
Mulai dari realisasi, bukan angan-angan
Tarik semua pengeluaran teknologi dari 12 bulan terakhir, hosting, langganan software, invoice kontraktor, proyek dev satu kali, retainer support. Bukan ingatan kasar soal itu, tapi angka aktual dari sistem akuntansi Anda. Inilah basis Anda. Sebagian besar pemilik bisnis melewatkan langkah ini karena melelahkan, lalu heran setiap tahun mengapa anggarannya tidak pernah sesuai kenyataan. Anggaran itu tidak sesuai kenyataan karena memang tidak pernah disusun dari kenyataan.
Setelah punya basisnya, kelompokkan ke tiga ember:
- Keep-the-lights-on (operasional wajib). Hosting, lisensi, kontrak support, apa pun yang bikin sesuatu berhenti berfungsi kalau Anda stop membayarnya.
- Perbaikan berkelanjutan. Pekerjaan dev yang terus berjalan, retainer maintenance, penambahan fitur inkremental pada sesuatu yang sudah live.
- Proyek satu kali. Apa pun yang terjadi sekali tahun ini dan tidak akan berulang, migrasi, pembangunan sistem baru, integrasi satu kali.
Anggaran tahun depan dimulai dari angka keep-the-lights-on tahun lalu, disesuaikan dengan perubahan yang sudah diketahui (karyawan baru yang butuh seat, kenaikan harga vendor yang sudah diberitahukan), ditambah pekerjaan perbaikan berkelanjutan yang berniat Anda lanjutkan.
Danai maintenance sebelum hal baru apa pun
Kesalahan penganggaran paling umum yang saya lihat adalah mendanai inisiatif baru lebih dulu dan memperlakukan maintenance sebagai sisa anggaran. Seharusnya sebaliknya. Kalau sistem yang sudah ada tidak didanai untuk tetap sehat, patch keamanan, dependency yang diperbarui, backup yang diuji, setiap proyek baru yang dibangun di atasnya ikut mewarisi risiko itu. Subscription creep adalah salah satu gejala dari belanja berkelanjutan yang tidak terkelola dengan baik; sistem inti yang tidak dirawat adalah gejala yang jauh lebih mahal, karena tagihannya muncul dalam bentuk outage, bukan baris anggaran.
Aturan kasar yang terbukti berlaku di berbagai klien SME yang saya tangani: alokasikan minimal 15 hingga 20 persen dari total belanja teknologi untuk maintenance dan upkeep sebelum mengalokasikan apa pun ke fitur atau tool baru. Kalau belanja Anda saat ini tidak punya pos maintenance yang eksplisit sama sekali, itu bukan efisiensi, itu biaya yang ditunda.
Batasi belanja eksperimental, dan kaitkan dengan sebuah keputusan
Setiap bisnis sebaiknya punya anggaran untuk mencoba hal baru, tool AI baru, integrasi percobaan, proof of concept. Masalahnya bukan pada keberadaan ember ini, tapi pada membiarkannya terbuka tanpa batas. Batasi sebagai persentase tetap dari total anggaran, saya memakai 10 hingga 15 persen, dan wajibkan setiap pos eksperimental punya tanggal keputusan dan metrik keberhasilan yang melekat sebelum satu Rupiah pun dikeluarkan.
"Kami mencoba tool customer service berbasis AI selama dua bulan, dan kami akan tahu itu berhasil kalau waktu resolusi turun 20 persen" itu layak didanai. "Kami akan menjajaki beberapa opsi AI tahun ini" bukan pos anggaran, itu angan-angan, dan angan-angan itulah yang berubah jadi antusiasme Januari lalu berakhir sebagai kebingungan Desember soal ke mana uangnya pergi.
Templatenya
| Kategori | % dari Anggaran (SME tipikal) | Aturan |
|---|---|---|
| Keep-the-lights-on | 40-50% | Berdasarkan realisasi, disesuaikan perubahan yang diketahui |
| Perbaikan berkelanjutan | 20-30% | Terikat pada inisiatif bernama dengan pemilik jelas |
| Maintenance dan upkeep | 15-20% | Batas bawah non-negosiabel, didanai sebelum pekerjaan baru |
| Eksperimental / baru | 10-15% | Dibatasi, dengan tanggal keputusan dan metrik per pos |
Setiap pos butuh pemilik, seseorang yang bertanggung jawab atas berhasil-tidaknya, dan hasil, sebuah hasil bisnis, bukan deskripsi teknis. "Migrasi ke hosting baru" adalah deskripsi teknis. "Turunkan biaya hosting 30 persen dan hilangkan outage yang terjadi di Q3" adalah hasil. Susun anggaran dengan cara kedua dan Anda benar-benar bisa mengevaluasi kinerjanya terhadap angka itu dalam dua belas bulan.
Meninjau di tengah tahun, bukan hanya di akhir tahun
Tetapkan check-in 90 hari khusus untuk ember eksperimental, di situlah drift terjadi paling cepat. Keep-the-lights-on jarang mengejutkan Anda. Belanja eksperimental tanpa check-in diam-diam berubah jadi enam langganan baru yang tidak ada yang ingat pernah menyetujuinya. Ini juga momen yang tepat untuk memasukkan apa pun yang ada di roadmap AI Anda untuk tahun ini, supaya inisiatif baru dievaluasi dengan disiplin anggaran yang sama seperti yang lain, bukan diperlakukan sebagai kategori terpisah yang tidak akuntabel hanya karena ada kata "AI" di namanya.
Intinya
Perencanaan anggaran IT tahunan yang dilakukan dengan baik itu membosankan, dan justru itulah intinya. Dasarkan pada realisasi, danai maintenance sebelum hal baru apa pun, batasi eksperimen dengan metrik yang melekat, dan berikan setiap pos seorang pemilik. Bisnis yang kaget dengan belanja teknologinya hampir selalu yang memulai dari wish list, bukan dari buku besar.