Jawaban singkat
Rencana AI 90 hari yang berguna tidak dimulai dengan membeli alat. Rencana ini dimulai dengan masalah bisnis, data awal, penanggung jawab, batas data, dan keputusan yang harus dibuat pada setiap titik keputusan.
Hari 1 sampai 15 dipakai untuk diagnosis. Hari 16 sampai 30 menyiapkan data dan penanggung jawab.
Hari 31 sampai 60 menjalankan 1 uji coba. Hari 61 sampai 90 menghasilkan penerapan terbatas atau keputusan berhenti.
Artikel ini adalah rencana keputusan, bukan janji penyerahan. Manajemen tetap memilih target, ambang lulus, vendor, anggaran, dan risiko yang dapat diterima.
Bedakan rencana 90 hari dari daftar aktivitas
Daftar aktivitas hanya menyebut rapat, demo, dan implementasi. Rencana keputusan menyebut output yang harus ada, pemiliknya, bukti yang diperiksa, dan kondisi untuk melanjutkan.
Mulai dengan 1 proses yang memiliki volume, input, output, dan pemeriksa manusia. Hindari proses yang belum stabil, menyentuh keputusan sensitif, atau belum memiliki pemilik proses bisnis.
Bab sebelumnya menjelaskan posisi perusahaan pada kesiapan perusahaan menghadapi era AGI dan cara menyatukan data menjadi alur kerja agentic. Bab ini mengubah rencana tersebut menjadi keputusan 90 hari yang dapat ditinjau.
Hari 1-15: diagnosis dan data awal
Pemilik proses bisnis memilih 3 sampai 5 kandidat pekerjaan. Setiap kandidat harus menjelaskan pemicu, input, langkah manusia, output, volume bulanan, waktu siklus, kesalahan umum, dan dampak jika output salah.
Ukur data awal dari sampel kerja nyata. Catat waktu kerja, tingkat kerja ulang, backlog, eskalasi, dan titik saat manusia mengubah atau menolak hasil.
Jangan memakai perkiraan yang dibuat setelah solusi dipilih. Data awal yang lemah membuat penghematan tampak besar tanpa pembanding yang dapat diuji.
Rubrik pemilihan use case
Gunakan rubrik berikut untuk membandingkan kandidat. Ini bukan model yang tervalidasi dan tidak memberi skor otomatis; penanggung jawab memilih bobot serta ambang berdasarkan risiko bisnis.
| Dimensi | Pertanyaan penanggung jawab | Sinyal awal |
|---|---|---|
| Dampak risiko | Jika output salah, siapa terdampak dan apa yang harus dipulihkan? | Mulai dari dampak yang dapat dibalik dan diperiksa. |
| Kesiapan data | Apakah input lengkap, legal dipakai, dan dapat ditelusuri? | Gunakan data yang memiliki penanggung jawab dan aturan akses. |
| Kejelasan proses | Apakah tim menjalankan langkah yang serupa? | Pilih variasi rendah pada uji coba pertama. |
| Nilai operasional | Apakah volume atau waktu tunggu bernilai bagi operasi? | Ukur kapasitas, kualitas, dan kerja ulang bersama. |
| Kontrol manusia | Siapa menyetujui output dan tindakan berikutnya? | Pastikan persetujuan sebelum aksi eksternal. |
Rubrik ini tidak membuktikan bahwa use case akan berhasil. Rubrik hanya membantu manajemen menolak kandidat yang datanya belum siap atau risikonya belum dapat dikendalikan.
Hari 16-30: siapkan data, penanggung jawab, dan batas
Setelah memilih 1 kandidat, tulis kontrak kerja sederhana. Kontrak menyebut tujuan uji coba, input yang diizinkan, data yang dilarang, output, penanggung jawab proses, peninjau, lokasi bukti, dan tindakan yang tidak boleh dilakukan agent.
Pisahkan hak baca, usulan, persetujuan, dan eksekusi. Pada uji coba awal, AI dapat membaca sumber yang disetujui dan menyiapkan usulan; manusia menyetujui setiap pengiriman, perubahan data, atau tindakan ke pelanggan.
Jika marketing menjadi kandidat, audit pengukuran lebih dulu. Data Health Audit memeriksa GA4, Pixel, CAPI, UTM, dan event untuk menemukan celah data marketing. Layanan ini bukan audit seluruh database perusahaan.
Jika sinyal iklan dan CRM tidak tersambung, Attribution Bridge dapat membantu menyusun GA4, Pixel, CAPI, event server-side, CRM, dan dashboard. Gunakan layanan ini ketika keputusan anggaran membutuhkan data funnel yang lebih utuh.
Hari 31-60: jalankan uji coba yang dapat dihentikan
Uji coba tidak membuktikan bahwa seluruh perusahaan siap memakai AI. Uji coba menguji 1 hipotesis dalam batas yang sempit, dengan data yang disetujui dan peninjauan manusia yang tersedia.
Tetapkan kelompok pembanding bila proses memungkinkan. Bandingkan output uji coba dengan data awal pada jenis pekerjaan yang sama, bukan dengan cerita keberhasilan dari minggu yang berbeda.
Catat setiap penolakan, koreksi, eskalasi, dan waktu peninjauan. Bukti ini lebih berguna daripada jumlah prompt, jumlah chat, atau jumlah dokumen yang dibuat.
Simulasi kapasitas, bukan klaim hasil
Simulasi ilustratif: tim menangani 1.000 kasus per bulan. Waktu data awal 12 menit per kasus. Setelah perubahan proses, waktu menjadi 7 menit dan angka itu sudah termasuk peninjauan manusia.
Selisihnya 5 menit per kasus, atau 5.000 menit per bulan. Itu setara 83,33 jam kapasitas yang tersedia kembali. Kapasitas tidak otomatis menjadi uang tunai, pendapatan, atau pengurangan staf.
Catat 83,33 jam sebagai kapasitas yang kembali. Jangan mencatatnya sebagai manfaat kas sebelum pengurangan biaya atau tambahan kas dapat dibuktikan.
Titik keputusan: lanjut, perbaiki, atau berhenti
Setiap titik keputusan membutuhkan kriteria lulus yang disetujui penanggung jawab sebelum uji coba dimulai. Contohnya dapat mencakup akurasi pada sampel, batas kerja ulang, waktu peninjauan, kepatuhan data, stabilitas integrasi, dan tidak adanya tindakan eksternal tanpa persetujuan.
- Lanjut: lanjut ke penerapan terbatas jika penanggung jawab menerima bukti kualitas, kontrol, dan beban operasi.
- Perbaiki: perbaiki prompt, data, SOP, atau peninjauan jika masalah dapat diisolasi dan risikonya tetap dapat dikelola.
- Berhenti: hentikan jika data tidak sah, output gagal memenuhi ambang penanggung jawab, biaya operasi tidak masuk akal, atau kontrol manusia tidak berjalan.
Titik keputusan berhenti adalah hasil yang sehat. Keputusan berhenti mencegah pengadaan yang lebih besar untuk masalah yang belum siap diotomasi.
Hari 61-90: penerapan terbatas atau penutupan yang rapi
Penerapan terbatas menambah pengguna, volume, atau variasi input secara bertahap. Jangan menambah semua divisi saat uji coba baru lulus pada 1 proses dan 1 kelompok pengguna.
Tulis runbook untuk input, peninjauan, eskalasi, fallback manual, akses, log, dan pemulihan. Tetapkan siapa yang menerima laporan mingguan dan siapa yang berwenang mengubah scope.
Jika uji coba dihentikan, simpan keputusan, bukti, batas yang ditemukan, dan kondisi yang harus berubah sebelum uji ulang. Penutupan seperti ini menjaga tim tidak mengulang eksperimen yang sama tanpa data baru.
Catatan penerimaan dan serah terima manajemen
Sebelum penerapan terbatas, penanggung jawab proses membuat catatan penerimaan. Catatan ini menyebut versi alur, sumber data, batas akses, sampel yang diperiksa, hasil terhadap ambang, temuan terbuka, dan keputusan penanggung jawab.
Contoh: penanggung jawab proses menerima uji coba hanya untuk ringkasan 1 jenis permintaan. Ia mencatat bahwa pengiriman ke pelanggan tetap memerlukan persetujuan manusia dan bahwa kasus di luar daftar harus diteruskan kepada penanggung jawab.
Catatan ini bukan formulir kosong. Catatan ini memberi tim operasi, keuangan, dan pengadaan bukti yang sama saat mereka menilai scope, biaya, dan perubahan berikutnya.
Nilai kapasitas dan biaya kas
Nilai kapasitas berbeda dari manfaat kas. Kapasitas bernilai jika tim menggunakannya untuk mengurangi antrean, meningkatkan peninjauan, atau melayani volume yang memang dapat ditangani.
Manfaat kas bersih bulanan = manfaat kas terverifikasi − biaya operasi bulanan.
Perkiraan bulan impas = biaya awal ÷ manfaat kas bersih bulanan. Gunakan rumus hanya saat manfaat tersebut positif dan stabil.
Biaya operasi dapat mencakup API, hosting, support, QA, dan peninjauan. Biaya awal dapat mencakup setup, integrasi, dan pelatihan.
Gunakan layanan sesuai tahap, bukan sebagai paket wajib
Kebutuhan marketing relevan ketika proses yang diuji memakai campaign, lead, konten, atau data penjualan online. Kebutuhan produk dan engineering relevan ketika uji coba membutuhkan aset digital atau pemulihan aplikasi yang sudah ada.
| Tahap | Kebutuhan | Layanan yang dapat dipertimbangkan |
|---|---|---|
| Diagnosis | Petakan use case, risiko, dan keputusan vendor. | AI Consulting atau AI Implementation Roadmap. |
| Data marketing | Periksa funnel, event, dan dashboard. | Digital Marketing Setup dan Attribution Bridge. |
| Operasi iklan | Campaign perlu tracking, catatan keputusan, dan peninjauan. | Setup Sistem Meta Ads dengan AI. |
| Konten dan discovery | Tim perlu workflow SEO dan AI Search yang dapat diperiksa. | Pelatihan AI SEO & GEO. |
| Penjualan online | Bisnis membutuhkan storefront dan checkout milik sendiri. | Jasa Pembuatan E-commerce, jika penjualan online memang menjadi scope. |
| Aplikasi dan tim teknis | Aplikasi perlu dipulihkan atau developer perlu capability internal. | Vibe Code Rescue atau Private AI Software Engineering Apprenticeship, jika perusahaan memiliki developer internal. |
| Pemeliharaan | Scope yang lulus perlu ritme peninjauan dan perawatan. | OS Care Retainer. |
Jangan menganggap semua layanan ini sebagai prasyarat. Pilih layanan hanya saat kebutuhan pada tahap tersebut memang ada dan penanggung jawab menyetujui scope.
Pilih dukungan sesuai kebutuhan
Jika rencana masih berhenti pada asumsi, AI Consulting dapat membantu memilih jalur kerja. Jika manajemen sudah menyetujui target dan titik keputusan, gunakan AI Implementation Roadmap untuk urutan sumber daya, tata kelola, dan penanda tahap.
Untuk landing page, tracking, campaign, lead management, dan dashboard awal, lihat Digital Marketing Setup. Jika operasi campaign membutuhkan monitoring, creative review, CAPI, dan catatan keputusan, lihat Setup Sistem Meta Ads dengan AI.
Jika kebutuhan utamanya kalender, brief, persetujuan, dan laporan konten, gunakan OS Module: Content Ops.
Jika tim perlu membuat aset SEO dan AI Search yang dapat diaudit, lihat Pelatihan AI SEO & GEO.
Jika penjualan online masuk scope, Jasa Pembuatan E-commerce dapat membangun storefront, katalog, checkout, dan tracking. Jika aplikasi hasil AI memerlukan stabilisasi, pilih Vibe Code Rescue.
Jika perusahaan memiliki developer internal dan ingin membangun capability melalui pekerjaan nyata, pertimbangkan Private AI Software Engineering Apprenticeship. Setelah scope lulus, OS Care Retainer membantu monitoring, peninjauan audit log, dan pembaruan model atau prompt.
Untuk operasi iklan yang berjalan berulang, Kelola Meta Ads Bulanan dapat dipertimbangkan setelah peninjauan. Ruang lingkup, operator, dan kapasitas dikonfirmasi setelah peninjauan kebutuhan; layanan ini tidak menjamin operator aktif sebelum konfirmasi tersebut.
Catatan ringkas tentang risiko dan SEO
NIST AI RMF Core menawarkan kerangka sukarela: Govern, Map, Measure, dan Manage. Gunakan sebagai cara menata keputusan dan bukti risiko; ini bukan sertifikasi atau hukum Indonesia.
Google Search Central menyatakan dasar SEO tetap berlaku untuk fitur AI. Google tidak meminta schema khusus untuk AI Overviews atau AI Mode, dan tidak menjamin indeks, peringkat, atau penayangan.
Langkah berikutnya
Jika manajemen belum dapat memilih kandidat atau penanggung jawab, mulai dari AI Consulting.
Jika target, data, penanggung jawab, dan titik keputusan sudah ada, gunakan AI Implementation Roadmap. Layanan ini dapat menyusun urutan implementasi, sumber daya, tata kelola, dan hasil awal.
Pertanyaan umum
Apakah 90 hari selalu sesuai untuk transformasi AI?
Tidak. Rencana 90 hari hanya sesuai jika data, akses, dan penanggung jawab tersedia. Ubah urutan atau hentikan tahap saat titik keputusan menunjukkan syarat belum terpenuhi.
Apakah kapasitas yang kembali selalu menjadi penghematan biaya?
Tidak. Kapasitas baru menjadi nilai bisnis jika penanggung jawab menggunakannya untuk backlog, kualitas, layanan, atau biaya yang benar-benar dapat diubah.
Kapan perusahaan harus menghentikan uji coba AI?
Hentikan uji coba saat data tidak sah, kualitas gagal memenuhi ambang penanggung jawab, kontrol manusia tidak berjalan, atau biaya dan risiko tidak dapat diterima.
