Pemborosan dalam Industri IT: Temuan IT Assessment yang Ternyata Juga Risiko Keamanan

Pemborosan dalam industri IT adalah setiap aktivitas, sumber daya, atau biaya dalam pengelolaan dan pengembangan teknologi informasi yang tidak menambah nilai bagi pengguna maupun bisnis. Sebagai contoh sebuah server yang menganggur, lisensi untuk karyawan yang sudah tidak aktif, insiden yang terus berulang, atau fitur aplikasi yang tidak pernah dipakai.

Yang jarang disadari, banyak pemborosan IT juga merupakan celah keamanan. Dalam proyek IT Assessment yang kami tangani, tiga pola temuan muncul berulang kali, dan ketiganya membuang biaya lebih sekaligus membuka risiko.

2 Cara Melihat Pemborosan dalam IT

Konsep pemborosan berasal dari Lean Service, yang awalnya dikembangkan pada bagian proses produksi. Di dunia IT, konsep ini dapat dipakai melalui pendekatan dua kerangka yang saling melengkapi:

Lensa	Kerangka	Cocok untuk
Operasional IT	Delapan waste Lean (DOWNTIME atau TIMWOODS)	Infrastruktur, layanan IT, help desk, dan pengelolaan aset
Pengembangan perangkat lunak	Tujuh waste versi Mary dan Tom Poppendieck	Tim pengembang aplikasi dan produk digital

Untuk penjelasan lengkap setiap waste dalam konteks umum insightnya ada pada artikel 8 pemborosan dalam Lean. Satu hal perlu dibedakan, pemborosan dalam IT tidak sama dengan "sampah digital". Sampah digital biasanya merujuk pada data dan file yang menumpuk tanpa guna, serta dampak lingkungannya. Pemborosan dalam IT lebih luas, karena mencakup proses, waktu, tenaga, dan biaya.

8 Pemborosan (Waste) pada Operasional IT

Berikut bentuk delapan waste Lean dalam operasional IT sehari-hari:

Waste	Contoh
Defects (cacat)	Bug dan insiden yang terus berulang, konfigurasi keliru yang memicu gangguan layanan
Overproduction (produksi berlebih)	Kapasitas server atau cloud jauh melebihi kebutuhan, laporan rutin yang tidak pernah dibaca
Waiting (menunggu)	Tiket tertahan menunggu persetujuan berlapis, aplikasi yang lambat merespons
Non-utilized talent (bakat tidak termanfaatkan)	Tenaga ahli tersita untuk pekerjaan manual yang bisa diotomatisasi, pengetahuan hanya dikuasai satu orang
Transportation (perpindahan)	Data dipindahkan antarsistem secara manual, tiket berpindah tangan berkali-kali sebelum ditangani
Inventory (persediaan berlebih)	Server menganggur, lisensi tidak terpakai, akun dan data yang sudah tidak dibutuhkan
Motion (gerakan berlebih)	Berpindah ke banyak aplikasi untuk menyelesaikan satu tugas, mencari dokumentasi yang tersebar
Extra-processing (proses berlebih)	Persetujuan berlapis untuk perubahan kecil, dokumentasi yang dibuat ganda

Satu konfigurasi yang keliru (defects) membuat aplikasi lambat (waiting), memicu banyak keluhan ke help desk, lalu sering "diselesaikan" dengan menambah kapasitas server yang sebenarnya tidak perlu (overproduction), efek domino tersebut patut untuk diwaspadai untuk meminimalisir pemborosan.

7 Waste dalam Pengembangan Perangkat Lunak

Pada 2003, Mary dan Tom Poppendieck mengadaptasi tujuh waste manufaktur untuk pengembangan perangkat lunak dalam buku Lean Software Development: An Agile Toolkit. Kerangka ini lebih tepat bagi tim pengembang dibanding daftar versi manufaktur.

Waste perangkat lunak	Padanan di manufaktur	Contoh
Pekerjaan setengah jadi	Inventory	Kode yang lama tidak di-merge, fitur selesai tetapi tidak dirilis
Fitur berlebih	Overproduction	Fitur yang dibangun "untuk berjaga-jaga" tetapi tidak pernah dipakai
Belajar ulang	Extra-processing	Tim harus memahami ulang kode atau keputusan lama karena tidak terdokumentasi
Handoff	Transportation	Konteks hilang saat pekerjaan berpindah dari analis ke pengembang lalu ke penguji
Penundaan	Waiting	Menunggu persetujuan, lingkungan uji, atau jawaban dari pengguna
Perpindahan tugas	Motion	Satu pengembang mengerjakan terlalu banyak proyek sekaligus
Cacat	Defects	Bug dan celah keamanan yang ditemukan terlambat

Pemetaan ke padanan manufaktur bisa sedikit berbeda antarsumber, namun ketujuh waste-nya konsisten.

Seberapa Besar Pemborosan Cloud?

Kenaikan ke 29% pada laporan 2026 mengakhiri tren penurunan sejak puncaknya pada 2022. Flexera mengaitkannya dengan biaya yang makin kompleks akibat beban kerja AI serta layanan IaaS dan PaaS baru, survei 2026 melibatkan 753 responden.

Satu catatan penting: angka ini adalah estimasi organisasi sendiri, bukan hasil audit. Pemborosan yang tidak terlihat oleh alat pemantau mereka tidak ikut terhitung, sehingga angka sebenarnya bisa lebih besar.

Polanya juga relevan bagi organisasi yang lebih kecil: kapasitas dan lisensi yang dibeli tanpa pemilik jelas cenderung terus dibayar, meski tidak lagi digunakan.

3 Temuan IT Assessment: Pemborosan yang Sekaligus Menjadi Risiko

Berikut tiga pola yang berulang kali yang kami temukan dalam proyek IT Assessment selama mendampingi klien. Ketiganya jarang dianggap pemborosan karena tidak muncul sebagai suatau tagihan, padahal biayanya nyata dan risikonya lebih besar lagi.

Temuan 1: Hak Akses (RBAC) Tidak Diperbarui dan Tidak Ditinjau

Struktur role-based access control (RBAC) disusun saat sistem pertama kali diterapkan, lalu tidak pernah ditinjau ulang. Peran bertambah, karyawan pindah divisi atau keluar, tetapi hak aksesnya tetap.

Mengapa ini pemborosan:

• Inventory: akun dan lisensi untuk pengguna yang tidak aktif terus dibayar.
• Extra-processing: permintaan akses ditangani satu per satu, karena peran yang ada tidak lagi mencerminkan pekerjaan sebenarnya.

Mengapa ini risiko:

• Hak akses menumpuk melebihi kebutuhan pekerjaan (privilege creep).
• Akun milik karyawan yang sudah keluar masih bisa dipakai, oleh siapa pun yang mengetahui kredensialnya.

Kontrol ISO/IEC 27001:2022 terkait: 5.15 (kontrol akses), 5.18 (hak akses, termasuk peninjauan dan pencabutannya), dan 8.2 (hak akses istimewa).

Cara memperbaikinya:

1. Tinjau hak akses secara berkala per peran, dimulai dari sistem kritis dan akun dengan hak istimewa.
2. Hubungkan proses HR (karyawan masuk, pindah, dan keluar) dengan pemberian dan pencabutan akses.
3. Terapkan prinsip hak akses minimum: setiap orang hanya mendapat akses yang dibutuhkan pekerjaannya.
4. Simpan hasil setiap peninjauan sebagai bukti.

Temuan 2: Insiden Tidak Ditangani sesuai Alur, dan Tanpa Lessons Learned

Yang kami temukan. Prosedur penanganan insiden sebenarnya ada, tetapi dalam praktik insiden ditangani dengan cara masing-masing. Langkah terakhir, yaitu menarik pelajaran dari insiden, paling sering terlewat. Begitu layanan pulih, insiden dianggap selesai.

Mengapa ini pemborosan:

• Defects: insiden yang sama terulang karena akar masalahnya tidak pernah ditangani.
• Waiting: eskalasi berputar-putar karena tidak jelas siapa mengerjakan apa.
• Non-utilized talent: pengetahuan dari insiden hanya tersimpan di kepala orang yang menanganinya, lalu hilang saat ia pindah atau keluar.

Mengapa ini risiko:

• Bukti insiden tidak terkumpul dan tersimpan dengan baik.
• Jika insiden melibatkan data pribadi, kewajiban pemberitahuan tertulis paling lambat 3 × 24 jam dalam UU PDP berisiko terlewat. Penjelasannya ada di panduan pelaksanaan UU PDP berdasarkan PP 33/2026.

Kontrol ISO/IEC 27001:2022 terkait: 5.24 sampai 5.26 (perencanaan, penilaian, dan respons insiden sesuai prosedur terdokumentasi) serta 5.27 (pembelajaran dari insiden untuk memperkuat kontrol).

Cara memperbaikinya:

1. Sederhanakan alur insiden menjadi tahapan yang jelas: deteksi, penilaian, respons, pemulihan, dan pembelajaran.
2. Tetapkan peran dan jalur eskalasi untuk setiap tingkat keparahan.
3. Jadikan tinjauan pasca-insiden sebagai syarat sebelum insiden dinyatakan selesai.
4. Catat lessons learned di tempat yang bisa dicari tim lain, lalu tindak lanjuti perubahan kontrolnya.
5. Latih karyawan cara mengenali dan melaporkan insiden, misalnya melalui training awareness.

Temuan 3: Pengembangan Aplikasi Tidak Mengikuti Kaidah Keamanan

Yang kami temukan. Aplikasi dikembangkan tanpa aturan keamanan sejak awal. Lingkungan kerja tidak dipisahkan dengan jelas, termasuk pemisahan antara komponen frontend dan backend. Pengujian keamanan baru dilakukan menjelang rilis, atau bahkan tidak sama sekali.

Mengapa ini pemborosan:

• Defects: celah yang ditemukan di akhir memaksa pengerjaan ulang, dan biayanya jauh lebih besar dibanding jika dicegah sejak perancangan.
• Waiting dan pekerjaan setengah jadi: fitur yang sudah selesai tertahan, menunggu perbaikan keamanan sebelum bisa dirilis.

Mengapa ini risiko:

• Perubahan bisa langsung masuk ke sistem produksi tanpa melewati pengujian.
• Data asli, termasuk data pribadi, dipakai di lingkungan pengembangan yang pengamanannya lebih longgar.
• Celah aplikasi lolos ke sistem yang dipakai pelanggan.

Kontrol ISO/IEC 27001:2022 terkait: 8.25 (siklus pengembangan yang aman), 8.27 (prinsip arsitektur sistem yang aman), 8.28 (secure coding), 8.29 (pengujian keamanan dalam pengembangan dan penerimaan), dan 8.31 (pemisahan lingkungan pengembangan, uji, dan produksi).

Cara memperbaikinya:

1. Tetapkan aturan pengembangan yang aman sejak tahap perancangan, bukan menjelang rilis.
2. Pisahkan lingkungan pengembangan, uji, dan produksi, termasuk hak akses dan datanya. Hindari memakai data pribadi asli di lingkungan uji.
3. Rancang arsitektur yang memisahkan komponen frontend dan backend, agar logika bisnis dan data sensitif tidak terbuka di sisi pengguna.
4. Jalankan pengujian keamanan di setiap siklus rilis, lalu uji sistem yang sudah berjalan secara berkala melalui vulnerability assessment atau penetration testing.

Cara Mengidentifikasi dan Mengurangi Pemborosan IT

Checklist berikut menggabungkan sisi efisiensi dan sisi keamanan. Gunakan untuk pemeriksaan awal sebelum asesmen yang lebih mendalam.

• [ ] Ada daftar aset, lisensi, dan langganan cloud, lengkap dengan pemilik masing-masing.
• [ ] Hak akses ditinjau berkala dan dicocokkan dengan data karyawan aktif.
• [ ] Tiket dan insiden yang berulang dianalisis setiap bulan untuk dicari akar masalahnya.
• [ ] Setiap insiden ditutup dengan tinjauan pasca-insiden.
• [ ] Waktu dari perubahan disetujui sampai masuk produksi diukur, termasuk seberapa sering harus dikerjakan ulang.
• [ ] Lingkungan pengembangan, uji, dan produksi dipisahkan.
• [ ] Sumber daya cloud diberi label pemilik dan proyek, agar biayanya bisa ditelusuri.
• [ ] Pengetahuan penting didokumentasikan, sehingga tidak bergantung pada satu orang.

Kabar baiknya, sebagian besar pemborosan IT tidak membutuhkan investasi baru, yang dibutuhkan adalah pemilik yang jelas dan peninjauan yang rutin.

Banyak kontrol di checklist ini juga merupakan bagian dari ISO/IEC 27001. Organisasi yang sudah atau sedang menerapkan standar tersebut bisa memakai kontrol yang sama untuk menekan pemborosan.

Kesimpulan

Pemborosan dalam industri IT tidak selalu tampak pada tagihan. Sebagian besar justru tersembunyi dalam hak akses yang tidak pernah ditinjau, insiden yang berulang tanpa pembelajaran, dan aplikasi yang dikembangkan tanpa kaidah keamanan. Ketiganya membuang biaya dan tenaga, sekaligus membuka celah yang bisa berujung pada insiden keamanan.

Maka penting dalam upaya mengurangi pemborosan IT dan memperkuat keamanan informasi sebaiknya dilakukan bersamaan.

Tim IT Assessment Mitra Berdaya Optima dapat membantu memetakan kondisi TI organisasi Anda, menemukan pemborosan yang sekaligus menjadi risiko, dan menyusun prioritas perbaikannya. Pelajari layanan IT Assessment MBO atau hubungi tim kami untuk berdiskusi dan segera hubungi konsultan MBO.