Modul 7 · Sambungkan dan otomasi
Kapan sebaiknya tidak mengotomasi
Intinya
Otomasi cocok untuk tugas yang sering, murah bila salah, dan bisa dibatalkan. Sisanya: AI menyiapkan, manusia memutuskan. Taruh titik periksa sebelum efek yang tidak bisa ditarik, dan periksa hasil akhirnya. Laporan sukses belum membuktikan apa-apa.
Setelah pelajaran ini kamu bisa
- Menilai tugas dari seberapa sering, akibat salah, dan bisa tidaknya dibatalkan
- Menempatkan titik periksa manusia di alur otomasi
- Mengenali tanda otomasi yang gagal tanpa suara
Istilah di pelajaran ini
Pahami
Otomasi artinya sebuah langkah berjalan sendiri tanpa kamu menekan tombol setiap kali: setiap email masuk dikategorikan, setiap formulir diringkas, setiap pagi laporan dibuat. Dengan AI, godaannya besar, karena hampir semua hal terasa bisa diotomasi. Sebelum memulai, nilai tugasnya dengan tiga pertanyaan:
- Seberapa sering? Tugas yang terjadi puluhan kali sehari menghemat banyak waktu bila diotomasi. Tugas yang terjadi dua kali setahun jarang sepadan dengan usaha membangun dan merawat otomasinya.
- Seberapa mahal bila salah? Salah memberi label folder pada email itu murah. Salah mengirim surat peringatan, salah menolak klaim, atau salah membayar vendor itu mahal, dan sering menyangkut orang.
- Bisa dibatalkan atau tidak? Label yang salah bisa diganti. Email yang sudah terkirim, uang yang sudah keluar, dan data yang sudah terhapus tidak bisa ditarik kembali.
Tugas yang sering, murah bila salah, dan bisa dibatalkan adalah calon otomasi yang baik. Begitu salah satu jawabannya buruk, ubah polanya menjadi AI menyiapkan, manusia memutuskan: AI membuat draf, kategori, atau usulan; manusia memeriksa dan menekan tombol. Untuk keputusan yang berdampak signifikan pada orang, ada juga hak hukum mereka yang perlu diperhitungkan; itu dibahas di pelajaran keputusan otomatis dan hak orang.
Satu tanda tambahan: kalau aturannya penuh pengecualian ("biasanya begini, kecuali klien lama, kecuali bulan Desember, kecuali ada surat dari direksi"), otomasi akan sering salah di tempat yang paling tidak terlihat. Mulailah dengan bagian yang aturannya jelas saja.
Kalau sebuah alur tetap diotomasi, tempatkan manusia di beberapa titik yang tepat. Titik periksa di setiap langkah membuat orang lelah, lalu mulai menyetujui tanpa membaca. Titik periksa paling penting ada tepat sebelum efek yang tidak bisa ditarik: sebelum email ke luar terkirim, sebelum pembayaran disetujui, sebelum data dihapus, sebelum keputusan tentang orang dicatat. Titik lain yang berguna adalah antrean pengecualian, tempat kasus yang tidak cocok dengan aturan atau yang membuat AI ragu masuk untuk ditangani manusia, dan pemeriksaan sampel, misalnya membaca sepuluh hasil acak setiap minggu.
Kegagalan yang berisik cepat ketahuan karena ada pesan error (galat) atau orang yang protes. Yang berbahaya adalah kegagalan yang diam: otomasinya tetap jalan, tetapi hasilnya tidak sampai. Tandanya:
- Laporan selalu "berhasil", tetapi tidak ada yang memeriksa hasil akhirnya.
- Jumlah yang diproses tiba-tiba turun ke nol, atau tidak berubah selama berhari-hari.
- Tidak ada keluhan, karena orang yang seharusnya menerima hasilnya tidak menerima apa-apa.
- Hasilnya persis sama setiap hari, padahal datanya berubah.
Periksa keadaan akhir: apakah email itu sampai di kotak masuk penerima, apakah angka di sistem tujuan berubah. Laporan prosesnya bisa saja bilang sukses. Catat setiap langkah otomasi dalam log audit supaya kamu bisa menelusuri apa yang terjadi, dan pasang peringatan bila dalam sehari tidak ada yang diproses.
Semua ini makin penting saat yang diotomasi adalah agen AI (AI agent), yaitu AI yang boleh memakai alat dan memutuskan langkah berikutnya sendiri. Agen bisa menjalankan puluhan langkah dalam beberapa menit, jadi satu salah paham di langkah awal bisa berlipat sebelum ada yang melihat. Prinsip manusia dalam kendali di sini berarti tiga hal yang konkret: agen berhenti dan meminta persetujuan sebelum tindakan yang tidak bisa dibatalkan, setiap langkahnya tercatat sehingga bisa ditelusuri, dan orang yang menyetujui membaca apa yang akan terjadi sebelum menekan tombol setuju. Persetujuan yang diberikan tanpa membaca sama saja dengan tidak ada titik periksa.
Sebelum
Permintaan
Buat alur otomatis: setiap email keluhan pelanggan yang masuk dibaca AI, AI membalas dengan solusi, lalu tiketnya ditutup.
Hasilnya
Alur dibuat. Contoh balasan otomatis: "Mohon maaf atas ketidaknyamanannya. Kami akan mengembalikan dana Anda secara penuh dalam 3 hari kerja." Tiket ditutup.
Sesudah
Permintaan
Saya ingin merancang alur keluhan pelanggan yang memakai AI, dengan manusia tetap memutuskan. Tujuan: tim layanan menjawab lebih cepat tanpa menjanjikan hal yang tidak boleh dijanjikan. Alur yang saya mau: AI membaca email keluhan, memberi kategori, dan menulis draf balasan berdasarkan panduan layanan yang saya tempel. Draf masuk antrean; petugas membaca, mengubah bila perlu, lalu mengirim. Batas: draf tidak boleh menjanjikan pengembalian dana, kompensasi, atau tanggal. Keluhan yang menyebut pengembalian dana, hukum, atau kesehatan masuk antrean khusus tanpa draf. Cek: setiap hari ada laporan jumlah email masuk, jumlah draf, dan jumlah yang dikirim petugas. Tulis alurnya langkah demi langkah dan tandai setiap titik periksa manusia.
Hasilnya
1. Email masuk, AI memberi kategori (pengiriman, produk, tagihan, lainnya). 2. Bila menyebut pengembalian dana, hukum, atau kesehatan: masuk antrean khusus, tanpa draf. [TITIK PERIKSA: petugas senior] 3. Selain itu: AI menulis draf dari panduan layanan, tanpa janji dana atau tanggal. 4. Draf masuk antrean. [TITIK PERIKSA: petugas membaca, mengubah, mengirim] 5. Tiket ditutup oleh petugas setelah pelanggan menjawab atau tujuh hari tanpa jawaban. 6. Laporan harian: masuk, draf, terkirim. Peringatan bila draf ada tetapi terkirim nol.
Yang berubah
- Versi pertama menjanjikan pengembalian dana penuh atas nama perusahaan, terkirim tanpa dibaca siapa pun, dan tidak bisa ditarik.
- Alur yang lebih baik mengotomasi bagian yang murah bila salah (kategori, draf) dan menaruh manusia sebelum efek yang tidak bisa dibatalkan (mengirim).
- Laporan harian dan peringatan "terkirim nol" menangkap kegagalan yang diam.
Kesalahan umum
- Kesalahan
- Menganggap otomasi berjalan baik karena statusnya selalu "berhasil".
- Kenapa merugikan
- Status hanya berarti proses selesai tanpa error yang terdeteksi. Hasilnya belum tentu benar atau sampai. Langkah bisa terlewat, data bisa kosong, dan pesan bisa tidak terkirim sementara status tetap hijau, seperti di kasus pelajaran ini, berminggu-minggu sebelum ada yang sadar.
- Lakukan ini
- Tambahkan satu pemeriksaan keadaan akhir di ujung setiap otomasi: hitung yang sampai atau berubah di sistem tujuan, bandingkan dengan yang masuk, dan baca beberapa hasil acak setiap minggu.
Coba
Kartu pilah
Untuk setiap tugas, pola mana yang paling tepat?
Membuat ringkasan notulen rapat untuk diperiksa
Mengirim surat teguran ke karyawan
Memasukkan diagnosis ke rekam medis pasien
Mengingatkan tenggat tugas tim setiap Senin
Menyetujui pembayaran tagihan vendor
Memberi label kategori pada email masuk
6 kartu lagi
Ini alur otomasi pengiriman tagihan bulanan. Baca setiap langkah dan pikirkan di mana titik periksanya.
Langkah 1 dari 5
AI menyusun tagihan dari data pemakaian
Murah bila salah selama belum terkirim. Belum perlu titik periksa.
Bawa pulang
Sebelum mengotomasi satu langkah
- Tugas ini sering, murah bila salah, dan bisa dibatalkan
- Aturannya jelas, tanpa banyak pengecualian
- Ada titik periksa manusia sebelum setiap efek yang tidak bisa ditarik
- Ada antrean pengecualian untuk kasus yang tidak cocok
- Keadaan akhir diperiksa dan dicatat; status "berhasil" saja tidak cukup
Yang salah di tempat kami
Pipeline hijau yang tidak mengganti apa pun
- Konteks
- Pipeline deploy kami mencadangkan database, lalu mengganti kontainer aplikasi dengan versi baru.
- Yang terjadi
- Langkah cadangan salah membaca input dan ikut menelan sisa skrip. Langkah penggantian kontainer tidak pernah berjalan, tetapi pipeline tetap melapor sukses.
- Dampaknya
- Beberapa rilis yang dianggap sudah live ternyata belum terpasang.
- Akar masalah
- Skrip tidak berhenti saat satu langkah gagal, dan tidak ada yang memeriksa versi yang sedang berjalan setelah deploy.
- Yang kami lakukan
- Langkah cadangan diperbaiki agar tidak membaca input skrip, dan rilis yang tertunda dipasang ulang. Satu aplikasi diserahkan ke pemiliknya untuk di-deploy ulang.
- Pengaman yang kami pasang
- Setiap langkah memeriksa kode keluarnya, dan pipeline diakhiri dengan memeriksa versi image yang sedang berjalan.
PelajarannyaHijau berarti skrip selesai; periksa sendiri bahwa perubahannya terpasang.
Artinya untuk kerjamuLaporan "berhasil" dari otomasi belum tentu berarti hasilnya sampai. Periksa hasil akhirnya sendiri, misalnya apakah email sampai ke kotak masuk penerima.
