Di Indonesia, minat terhadap teknologi terus bergerak cepat. Hari ini orang membahas AI untuk layanan pelanggan, besok ramai soal otomasi, lalu muncul lagi software akuntansi, CRM, POS, no-code, sampai cloud yang diklaim bisa memangkas biaya. Masalahnya, keputusan buruk sering terjadi sebelum proyek benar-benar berjalan. Tim sudah terpikat nama produk, demo terlihat meyakinkan, atau ikut arus tren, padahal kebutuhan dasarnya sendiri belum rapi.
Akibatnya tidak kecil. Biaya langganan membesar, integrasi ke sistem lama macet, data sulit dipindahkan, tim operasional kewalahan, dan proyek yang seharusnya mempercepat kerja justru menambah beban. Dalam banyak kasus, kesalahan bukan karena teknologinya jelek, tetapi karena teknologi dipilih dengan logika yang salah: terlalu cepat membeli, terlalu cepat membangun, atau terlalu percaya bahwa tool populer pasti cocok.
Artikel ini membahas cara menghindari keputusan buruk saat memilih teknologi sebelum memulai dengan sudut yang berbeda: bukan sekadar daftar tips umum, melainkan kerangka keputusan pra-proyek yang bisa dipakai startup, UMKM, tim produk, sekolah, klinik, atau organisasi di Indonesia. Fokusnya adalah kebutuhan nyata, risiko jangka panjang, biaya total, kemampuan tim, dan ruang untuk berubah ketika kondisi bisnis ikut berubah.
Kenapa Banyak Pilihan Teknologi Gagal sejak Awal
Kegagalan pemilihan teknologi jarang dimulai dari bug. Kegagalan biasanya lahir dari asumsi. Tim mengira masalahnya sederhana, vendor dianggap pasti bisa mengikuti proses internal, atau manajemen percaya bahwa satu platform dapat menyelesaikan semua hal sekaligus. Saat implementasi dimulai, asumsi itu pecah satu per satu.
Efek ikut tren lebih kuat daripada kebutuhan
Salah satu pola paling umum adalah tool-first thinking. Orang lebih dulu bertanya, produk AI apa yang sedang naik, software mana yang paling sering muncul di media sosial, atau stack apa yang dipakai perusahaan besar. Pertanyaan seperti itu memang terdengar modern, tetapi tidak otomatis relevan. Teknologi yang cocok untuk perusahaan dengan tim data, DevOps, dan anggaran besar belum tentu cocok untuk bisnis yang baru punya satu admin, satu PIC operasional, dan proses kerja yang masih manual.
Di Indonesia, pola ini terlihat jelas ketika bisnis kecil langsung ingin mengadopsi sistem yang kompleks padahal masalah utamanya masih dasar: data pelanggan belum rapi, alur persetujuan masih lewat chat, atau laporan penjualan belum konsisten. Dalam kondisi seperti itu, membeli sistem yang sangat canggih justru memperbesar kekacauan.
Demo terlihat mulus, operasional belum tentu
Vendor biasanya menunjukkan skenario terbaik. Dashboard rapi, automasi berjalan, notifikasi masuk tepat waktu. Namun demo sering tidak memperlihatkan hal yang paling mahal saat go-live: migrasi data lama, penyesuaian hak akses, pelatihan tim, koneksi ke sistem lain, dan penanganan kasus pengecualian. Jika keputusan dibuat hanya dari presentasi, tim sedang membeli gambaran, bukan kesiapan operasional.
Menyalin stack perusahaan lain tanpa konteks
Banyak tim terjebak pada logika, jika perusahaan besar memakai ini, berarti ini aman. Padahal panduan resmi seperti GOV.UK Service Manual justru menekankan pentingnya memahami lanskap teknologi, kebutuhan pengguna, integrasi, dan ruang untuk berubah. Perusahaan besar bisa memilih teknologi tertentu karena punya sejarah sistem lama, kebutuhan skala, kontrak vendor, atau alasan keamanan yang tidak terlihat dari luar. Menyalin tanpa konteks hanya memindahkan keputusan orang lain ke masalah Anda sendiri.
Keputusan terlalu dini mengunci masa depan
Kesalahan lain adalah membuat keputusan jangka panjang ketika informasi masih minim. Misalnya langsung menetapkan satu vendor untuk beberapa tahun, membangun arsitektur terlalu rumit dari hari pertama, atau melakukan kustomisasi besar pada produk jadi. Keputusan dini seperti ini terasa cepat di awal, tetapi mahal saat bisnis perlu berubah. Padahal teknologi yang sehat harus memberi ruang untuk evolusi, bukan memaksa tim bertahan pada keputusan yang dibuat ketika pengetahuan masih dangkal.
Mulai dari Masalah, Bukan dari Nama Tools
Langkah paling penting sebelum membandingkan teknologi adalah merapikan definisi masalah. Jika tim tidak sepakat soal masalah, tidak ada alat evaluasi yang akan menyelamatkan keputusan. Karena itu, pembahasan awal seharusnya bukan software apa yang ingin dipakai, melainkan hasil apa yang ingin dicapai dan hambatan apa yang ingin dihilangkan.
Lima pertanyaan discovery yang wajib dijawab
- Masalah apa yang paling mahal hari ini? Apakah keterlambatan input data, follow-up pelanggan yang bocor, stok yang tidak sinkron, atau approval yang terlalu lama?
- Siapa pengguna utamanya? Admin, sales lapangan, supervisor, pemilik bisnis, tim gudang, atau pelanggan akhir?
- Proses mana yang harus membaik lebih dulu? Jangan mencoba memperbaiki seluruh organisasi sekaligus.
- Apa batasan nyata yang tidak bisa diabaikan? Anggaran, koneksi internet cabang, kemampuan tim, perangkat yang dipakai, kebutuhan audit, atau lokasi data.
- Apa konsekuensi jika solusi harus diganti dalam 12 sampai 24 bulan? Pertanyaan ini penting untuk mengukur risiko lock-in sejak awal.
Kalau lima pertanyaan ini belum terjawab, berhenti dulu. Memilih vendor pada tahap itu hanya memindahkan kebingungan ke dokumen kontrak.
Petakan alur kerja, bukan sekadar fitur
Banyak organisasi memilih teknologi dari daftar fitur. Padahal yang lebih berguna adalah memetakan alur kerja sebenarnya. Contoh sederhana: sebuah bisnis distribusi ingin membeli CRM. Jika mereka hanya membandingkan fitur kontak, broadcast, dan dashboard, mereka akan melewatkan proses penting seperti siapa yang memasukkan prospek, bagaimana lead dibagi, kapan follow-up dianggap terlambat, siapa yang menyetujui diskon, dan bagaimana data penjualan kembali ke laporan keuangan.
Dengan memetakan alur kerja, tim bisa melihat titik gesek yang nyata. Kadang masalahnya ternyata bukan butuh platform baru, melainkan butuh struktur data yang lebih disiplin, integrasi ringan, atau aturan operasional yang lebih jelas.
Tentukan hasil yang bisa diukur sejak awal
Sebelum menyentuh demo atau proposal harga, buat target yang bisa diuji. Misalnya:
- Waktu pembuatan laporan turun dari 2 hari menjadi 2 jam.
- Prospek yang tidak ditindaklanjuti dalam 24 jam turun minimal 50 persen.
- Input stok dari cabang masuk ke pusat tanpa rekap manual.
- Tim baru bisa belajar menggunakan sistem inti dalam waktu kurang dari 3 hari.
Target seperti ini akan membuat diskusi menjadi objektif. Tim tidak lagi berdebat soal produk mana yang terlihat keren, tetapi soal mana yang paling mungkin mencapai hasil yang dibutuhkan.
Kriteria Wajib sebelum Menentukan Stack
Setelah masalah didefinisikan, barulah teknologi dibandingkan. Di tahap ini, Anda membutuhkan checklist yang lebih kuat daripada kesan demo. Pendekatan yang sehat sejalan dengan panduan resmi GOV.UK tentang kebutuhan pengguna, standar terbuka, integrasi, keamanan, dan strategi pembelian. Untuk kualitas produk, kerangka seperti ISO/IEC 25010 juga membantu agar penilaian tidak berhenti di fitur permukaan saja.
Sepuluh kriteria yang paling menentukan
Gunakan tabel berikut untuk menilai setiap opsi secara objektif. Anda bisa memberi skor 1 sampai 5 pada setiap baris, lalu mendiskusikan bukti di balik nilainya.
| Kriteria | Pertanyaan Evaluasi | Tanda Risiko |
|---|---|---|
| Kecocokan kebutuhan inti | Apakah solusi benar-benar menyelesaikan 2 sampai 3 masalah utama, bukan hanya menambah fitur baru? | Fitur banyak tetapi alur inti masih perlu workaround manual. |
| Kemudahan integrasi | Bisakah sistem terhubung ke software yang sudah dipakai, API, ekspor data, atau middleware yang realistis? | Integrasi hanya dijanjikan, belum pernah dibuktikan di lingkungan serupa. |
| Keamanan dan privasi | Bagaimana kontrol akses, audit log, backup, enkripsi, dan pengelolaan data sensitif? | Vendor sulit menjelaskan kontrol dasar atau hanya memberi jawaban pemasaran. |
| Reliabilitas | Seberapa stabil sistem saat dipakai harian, saat traffic naik, atau ketika koneksi tidak ideal? | Belum ada bukti performa, SLA kabur, atau downtime sering dikeluhkan. |
| Performa | Apakah aplikasi tetap cepat pada perangkat dan jaringan yang umum dipakai tim Anda? | Demo mulus, tetapi uji nyata di laptop dan internet kantor lambat. |
| Kemudahan operasional | Siapa yang akan mengelola user, training, update, monitoring, dan troubleshooting setelah go-live? | Semua tergantung vendor atau satu orang internal saja. |
| Dukungan vendor dan dokumentasi | Apakah dokumentasi jelas, onboarding memadai, dan dukungan responsif? | Jawaban lambat, dokumentasi tipis, atau terlalu banyak informasi tersebar. |
| Biaya total kepemilikan | Selain lisensi, berapa biaya implementasi, integrasi, migrasi, pelatihan, support, dan perubahan kontrak? | Harga awal murah tetapi biaya tambahan muncul di setiap tahap. |
| Fleksibilitas perubahan | Jika proses bisnis berubah, apakah sistem bisa disesuaikan tanpa proyek besar? | Setiap perubahan kecil harus melalui vendor dan biaya baru. |
| Strategi keluar | Jika ingin pindah nanti, apakah data mudah diekspor, struktur data dipahami, dan kontrak tidak menahan terlalu lama? | Format data tertutup, terminasi rumit, atau ketergantungan tinggi pada komponen khusus. |
Jangan pisahkan kualitas dari bisnis
Banyak tim menilai produk hanya dari dua sisi: fitur dan harga. Itu terlalu sempit. Model kualitas seperti ISO/IEC 25010 mengingatkan bahwa produk TIK harus dinilai dari karakteristik kualitas yang lebih luas, seperti kesesuaian fungsi, keandalan, keamanan, kemudahan dipelihara, dan kompatibilitas. Dalam bahasa praktis: teknologi yang terlihat murah bisa jadi mahal jika sering error, sulit diperbarui, atau membuat tim tergantung pada tenaga spesialis tertentu.
Vendor bagus harus mudah diperiksa, bukan hanya pandai menjual
Mintalah bukti, bukan janji. Dokumen yang layak diminta sebelum keputusan besar antara lain:
- contoh skenario implementasi yang mirip dengan kebutuhan Anda,
- penjelasan alur integrasi,
- struktur biaya yang lengkap,
- kebijakan backup dan pemulihan,
- opsi ekspor data dan prosedur terminasi,
- roadmap produk untuk 12 bulan ke depan.
Jika vendor kesulitan menjelaskan hal-hal dasar ini, risiko sebenarnya sudah muncul sebelum kontrak ditandatangani.
Cara Menilai Build, Buy, atau Kustomisasi
Ini salah satu keputusan paling mahal. Salah pilih di sini bisa membuat organisasi terlalu bergantung pada vendor, atau sebaliknya terlalu percaya diri membangun semuanya sendiri. Tidak ada jawaban universal. Yang ada adalah konteks.
Kapan lebih masuk akal membangun sendiri
Membangun sendiri layak dipertimbangkan jika kebutuhan Anda benar-benar unik, menjadi pembeda bisnis, sulit dipenuhi produk pasar, dan tim memiliki kapasitas untuk mengembangkan sekaligus memeliharanya. Panduan pengadaan GOV.UK juga menekankan bahwa pilihan build lebih relevan ketika solusi komersial tidak mampu diskalakan, diadaptasi, atau diintegrasikan untuk kebutuhan inti.
Contohnya, perusahaan logistik dengan model operasional khas mungkin perlu membangun modul penjadwalan atau optimasi rute sendiri karena proses itu langsung memengaruhi margin dan pengalaman pelanggan. Namun membangun sistem inti bukan sekadar proyek awal. Anda juga sedang berkomitmen pada perawatan bug, patch keamanan, perubahan regulasi, dokumentasi, dan pergantian personel di masa depan.
Kapan membeli produk jadi lebih rasional
Membeli produk jadi lebih rasional bila kebutuhan Anda sebenarnya umum: akuntansi, helpdesk, manajemen tiket, POS, CRM standar, HRIS dasar, atau kolaborasi dokumen. Jika pasar sudah menyediakan solusi yang memenuhi sebagian besar kebutuhan, membeli biasanya lebih cepat dan lebih murah daripada membangun dari nol.
Tetapi hati-hati pada godaan mengutak-atik berlebihan. Panduan resmi pengadaan mengingatkan bahwa modifikasi kecil pada produk jadi dapat menghilangkan banyak manfaat utamanya. Begitu sistem terlalu banyak diubah, update jadi sulit, biaya support naik, dan upgrade di masa depan berubah menjadi proyek baru.
Kapan kustomisasi minimal adalah jalan tengah terbaik
Sering kali pilihan terbaik bukan build penuh dan bukan buy mentah-mentah, melainkan konfigurasi cermat dengan kustomisasi minimal. Misalnya menggunakan software jadi untuk fungsi umum, lalu menambahkan integrasi ringan atau modul kecil di bagian yang benar-benar membedakan bisnis.
Strategi ini cocok untuk banyak organisasi di Indonesia yang ingin bergerak cepat tetapi belum siap memikul beban pengembangan penuh. Kuncinya adalah disiplin: kustomisasi hanya dilakukan pada proses yang betul-betul penting, bukan karena tim enggan menyesuaikan kebiasaan kerja.
Gunakan logika 60-30-10 untuk menahan ego keputusan
Agar diskusi build vs buy tidak dikuasai opini paling keras, pakai pembobotan sederhana:
- 60 persen untuk kecocokan kebutuhan inti dan dampak bisnis.
- 30 persen untuk operasional, integrasi, keamanan, dan biaya jangka panjang.
- 10 persen untuk inovasi, tren, atau potensi eksperimen.
Dengan model ini, teknologi yang sedang populer tidak otomatis menang jika kebutuhan inti dan beban operasionalnya lemah.
Lakukan Uji Kecil sebelum Komitmen Besar
Sebelum kontrak besar, lakukan uji kecil. Ini salah satu pelindung terbaik terhadap keputusan emosional. GOV.UK secara eksplisit mendorong penggunaan prototipe dan percobaan skala kecil untuk menguji asumsi, integrasi, pengalaman pengguna, dan kesiapan implementasi.
Fokus pada satu masalah kecil tetapi sulit
Uji kecil bukan berarti demo tambahan. Uji kecil berarti memilih satu skenario yang cukup merepresentasikan kompleksitas nyata. Misalnya:
- sinkronisasi stok dari dua cabang ke pusat,
- alur approval diskon dengan batas nominal berbeda,
- pengiriman tiket pelanggan dari WhatsApp ke dashboard support,
- migrasi sebagian data pelanggan lama ke sistem baru.
Jika teknologi gagal pada satu masalah yang kecil tetapi kritis, Anda mendapat sinyal penting sebelum menghabiskan anggaran lebih besar.
Apa saja yang harus diuji
- Kesesuaian proses: apakah langkah kerja terasa alami atau justru memaksa tim membuat jalan memutar?
- Integrasi: apakah data benar-benar masuk dan keluar dengan format yang bisa dipakai?
- Pengalaman pengguna: apakah staf nonteknis dapat belajar tanpa kebingungan berlebihan?
- Kinerja nyata: apakah sistem masih layak saat dipakai di perangkat dan jaringan sehari-hari?
- Kesiapan operasi: siapa yang bisa menangani masalah pertama tanpa menunggu vendor terus-menerus?
Buat batas waktu dan kriteria lulus yang jelas
Uji kecil yang terlalu lama berubah menjadi proyek tanpa arah. Idealnya, tetapkan durasi singkat, misalnya 2 sampai 4 minggu, dengan kriteria lulus sederhana. Contoh:
- 90 persen data percobaan berhasil masuk tanpa pembersihan manual besar.
- Tim operasional bisa menyelesaikan tugas inti setelah 2 sesi pelatihan.
- Tidak ada hambatan integrasi yang memerlukan pengembangan besar di luar rencana.
- Biaya implementasi awal masih sesuai perkiraan.
Kalau hasilnya gagal, itu bukan kegagalan proyek. Itu justru keberhasilan proses seleksi karena kesalahan ditemukan sebelum menjadi beban permanen.
Tanda Bahaya yang Harus Membuat Anda Menunda Keputusan
Tidak semua keputusan harus dipercepat. Kadang menunda selama dua minggu jauh lebih murah daripada menyesal dua tahun. Berikut beberapa sinyal merah yang sebaiknya dianggap serius.
Kebutuhan belum selesai, tetapi vendor sudah diminta kirim proposal final
Jika internal Anda sendiri belum sepakat soal prioritas, ruang lingkup, dan pengguna utama, proposal final hanya akan mengunci kebingungan dalam angka.
Vendor sulit menjelaskan jalan keluar jika hubungan berakhir
NIST menekankan bahwa risiko rantai pasok teknologi tidak hanya soal serangan siber, tetapi juga rendahnya visibilitas terhadap cara produk dikembangkan, diintegrasikan, dan dipelihara. Dalam praktik, salah satu pertanyaan paling penting adalah: jika kami berhenti, bagaimana data, proses, dan akses kami dipindahkan? Bila jawabannya kabur, risiko vendor lock-in tinggi.
Semua hal penting masih disebut nanti bisa diatur
Kalimat seperti nanti bisa dikustom, nanti dibantu partner, atau nanti dibahas saat implementasi terdengar fleksibel, tetapi sering menjadi sumber biaya tersembunyi. Hal yang kritis harus jelas sebelum keputusan dibuat.
Tim internal tidak punya pemilik operasional
Teknologi tanpa pemilik internal akan cepat kehilangan arah. Selalu harus ada orang atau unit yang bertanggung jawab terhadap proses, data, pelatihan, dan evaluasi hasil. Jika semuanya hanya diserahkan ke vendor, organisasi sedang membeli ketergantungan.
Harga terlihat murah karena biaya penting belum dimasukkan
Waspadai harga lisensi yang tidak memasukkan migrasi, integrasi, training, support tingkat lanjut, penambahan user, kebutuhan penyimpanan, perubahan kontrak, atau biaya keluar. Banyak keputusan buruk tampak hemat hanya karena perhitungan belum lengkap.
Arsitektur terlalu rumit untuk tahap bisnis sekarang
Jika bisnis masih mencari kecocokan pasar, jangan buru-buru memasang arsitektur yang meniru perusahaan dengan skala nasional. Kompleksitas yang terlalu cepat justru memperlambat eksperimen dan memperbesar biaya koordinasi.
Kerangka Keputusan Sederhana agar Tim Tidak Berdebat Tanpa Arah
Setelah semua diskusi, tim tetap butuh mekanisme penutup yang rapi. Tanpa itu, rapat akan berulang, argumen makin subjektif, dan keputusan tertunda terus. Solusi paling praktis adalah memakai memo keputusan satu halaman yang wajib diisi untuk setiap opsi utama.
Isi memo keputusan satu halaman
- Masalah inti: satu paragraf tentang masalah yang mau diselesaikan.
- Pengguna utama: siapa yang akan paling sering memakai sistem.
- Tiga kebutuhan wajib: hal yang tidak boleh gagal dipenuhi.
- Tiga risiko terbesar: integrasi, biaya, keamanan, ketergantungan vendor, atau kesiapan tim.
- Hasil uji kecil: apa yang lolos dan apa yang belum terbukti.
- Biaya tahun pertama dan biaya berjalan: jangan gabungkan keduanya.
- Rencana keluar: bagaimana data diekspor dan proses dipindahkan jika diperlukan.
- Keputusan akhir: pilih, tunda, atau gugurkan, beserta alasan singkat.
Batasi opsi serius maksimal tiga
Semakin banyak opsi, semakin besar energi habis untuk perbandingan yang tidak produktif. Pilih maksimal tiga kandidat serius. Ini memaksa tim menyaring pasar lebih awal dan menjaga evaluasi tetap fokus.
Tentukan siapa yang memutuskan dan siapa yang memberi masukan
Sumber debat tanpa arah sering bukan pada teknologinya, melainkan pada tata kelola keputusan. Tetapkan dari awal siapa pengambil keputusan akhir, siapa pengguna inti yang wajib didengar, siapa evaluator teknis, dan siapa penanggung jawab anggaran. Dengan struktur itu, diskusi menjadi lebih adil dan tidak didominasi jabatan atau opini paling keras.
Gunakan prinsip bisa berubah, bukan harus sempurna
Pilihan teknologi yang baik bukan selalu yang paling lengkap hari ini, melainkan yang memungkinkan organisasi belajar, berkembang, dan berubah tanpa biaya pindah yang menghancurkan. Karena itu, saat ragu, utamakan solusi yang mudah dioperasikan, mudah diintegrasikan, dan mudah ditinggalkan jika arah bisnis berubah.
FAQ tentang Memilih Teknologi sebelum Memulai
Lebih baik memilih teknologi yang populer atau yang paling cocok dengan kebutuhan tim?
Yang paling cocok dengan kebutuhan tim. Popularitas bisa menjadi sinyal bahwa ekosistem, komunitas, atau talenta tersedia, tetapi itu hanya salah satu faktor. Jika proses inti, kemampuan tim, dan biaya operasional tidak cocok, popularitas tidak akan menyelamatkan implementasi.
Kapan sebaiknya startup kecil menghindari membangun sistem sendiri?
Saat kebutuhan dasarnya masih umum, tim teknis masih kecil, prioritas bisnis sering berubah, dan keunggulan kompetitif belum bergantung pada software khusus. Dalam kondisi seperti itu, membeli atau mengonfigurasi solusi jadi biasanya lebih cepat dan lebih aman.
Bagaimana cara mengetahui bahwa sebuah vendor berisiko menimbulkan lock-in?
Lihat empat hal: kemudahan ekspor data, ketergantungan pada format tertutup, biaya terminasi atau migrasi, dan seberapa banyak proses Anda harus dibangun dengan logika khusus vendor tersebut. Jika vendor sulit menjelaskan jalan keluarnya, risikonya tinggi.
Kesimpulan
Cara menghindari keputusan buruk saat memilih teknologi sebelum memulai bukan dengan menebak tren yang paling aman, melainkan dengan memperjelas masalah, menguji asumsi kecil lebih dulu, dan memaksa setiap opsi melewati evaluasi yang objektif. Panduan resmi seperti GOV.UK menekankan kebutuhan pengguna, standar terbuka, integrasi, pembelian yang matang, dan ruang untuk perubahan. Sementara itu, kerangka kualitas seperti ISO/IEC 25010 dan perhatian NIST pada risiko rantai pasok mengingatkan bahwa keputusan teknologi selalu menyangkut lebih dari sekadar fitur.
Jika Anda ingin keputusan yang lebih sehat, pegang tiga prinsip ini: mulai dari masalah, hitung biaya sepanjang siklus hidup, dan pastikan selalu ada jalan keluar. Dengan begitu, teknologi yang dipilih tidak hanya terlihat bagus saat presentasi, tetapi benar-benar membantu tim bergerak lebih cepat, lebih aman, dan lebih fleksibel ketika bisnis berkembang.
Referensi
- GOV.UK Service Manual – Choosing technology: an introduction – Panduan resmi yang langsung membahas cara mengambil keputusan teknologi, termasuk memahami konteks, membuat prototipe, menghindari lock-in, dan memberi ruang untuk perubahan.
- GOV.UK – Define your purchasing strategy – Relevan untuk bagian build vs buy, konfigurasi vs kustomisasi, uji coba produk, integrasi, dan risiko biaya jangka panjang sebelum memilih teknologi.
- GOV.UK – The Technology Code of Practice – Memberi kriteria resmi untuk merancang, membeli, dan membangun teknologi dengan mempertimbangkan kebutuhan pengguna, standar terbuka, keamanan, privasi, integrasi, dan keberlanjutan.
- ISO/IEC 25010:2023 – Product quality model – Standar resmi untuk menilai kualitas produk TIK atau software, berguna sebagai kerangka evaluasi agar pilihan teknologi tidak hanya berdasarkan tren atau fitur permukaan.
- NIST SP 800-161 Rev. 1 Update 1 – Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations – Rujukan kuat untuk mengevaluasi risiko vendor, rantai pasok, keamanan, reliabilitas, dan kualitas teknologi yang akan diadopsi organisasi.
