Implementasi AI termasuk proyek paling overwhelming yang bisa diambil perusahaan. Hampir mustahil gagal juga, asal prosesnya benar.
Kedengarannya bertentangan. Luke Pierce nulis, setelah empat tahun dan lebih dari 90 implementasi automation dan AI, overwhelm dan kegagalan datang dari tempat yang sama: ngerjain proyek tanpa proses.
Dia founder Boom Automations. Mereka bangun custom AI operating system untuk perusahaan jasa $2M sampai operasi $100M ke atas. Artikelnya membeberkan cara mereka benar-benar menjalankan engagement, termasuk istilah internal yang jarang dipublikasikan provider lain.
Minggu lalu dia 14 konsultasi. Hampir semua percakapan polanya sama.
Founder atau CEO masuk call sudah yakin AI penting. Beberapa orang di tim pakai ChatGPT untuk email dan ringkasan. Enam bulan lalu ada yang dorong AI strategy; hasilnya dokumen, tidak ada yang dibangun. Perusahaan jalan di antara 15 dan 25 software. Kebenaran operasionalnya hidup di spreadsheet yang dijaga satu orang, CRM yang akurat kira-kira 60%, dan ingatan dua atau tiga karyawan yang tidak pernah bisa cuti bersamaan. Orang terbaik mereka habis 8 sampai 15 jam seminggu ngetik ulang data, kejar status, bikin ulang laporan yang sama.
Ditanya mau bangun apa, jawabannya hampir selalu: "Kami tidak tahu. Makanya kami ngobrol sama kamu."
Itu bukan masalah building. Itu masalah knowing-what-to-build. Yang rusak strukturnya: cara operasi menyimpan dan memindahkan informasi.
Data silo: kenapa tidak ada yang bisa jawab "otomatisasi yang mana?"
Data silo adalah tempat informasi operasional hidup yang sistem lain tidak bisa lihat. CRM silo. Tool project management silo. Spreadsheet ops manager tahun 2021 yang diam-diam ditopang seluruh perusahaan, biasanya silo terbesar.
Silo tidak lahir karena satu keputusan bodoh. Tiap departemen menyelesaikan masalahnya sendiri, dengan tool sendiri, di titik pertumbuhan yang berbeda. Sales beli CRM di tahun kedua. Operasi pakai tool project management di tahun ketiga. Finance dari awal sudah sistem sendiri. Masing-masing masuk akal sendirian. Lima tahun kemudian, klien yang sama ada di enam sistem, dengan enam versi kebenaran yang sedikit berbeda. Tidak ada yang memutuskan itu.
Biayanya kelihatan di empat pola yang hampir selalu ketemu di assessment.
Re-entry. Informasi yang sama diketik tangan ke dua, tiga, atau empat sistem. Tiap entri peluang typo yang jadi masalah hilir, lalu seseorang habis sejam mengurai.
Version conflict. Dua sistem tidak setuju soal status klien. Orang harus berhenti, tentukan yang mana yang benar. Kerja rekonsiliasi itu berulang, tiap klien, tiap minggu.
Reporting lag. Pertanyaan leadership yang mestinya 30 detik, jawabannya dua hari, karena harus tarik manual dari empat sumber lalu meratakan perbedaannya.
Tribal knowledge. Sistem paling penting ternyata ingatan beberapa karyawan senior. Operasi macet waktu mereka tidak ada, pecah waktu mereka pergi.
Untuk AI, silo jadi lebih berbahaya, bukan lebih aman. Agent yang kerja di context parsial tidak akan bilang ia cuma pegang sepertiga gambar. Ia akan kasih jawaban fasih dan percaya diri dari sepertiga itu. Data terfragmentasi yang dimasukkan ke AI menghasilkan kesalahan yang dipoles, dalam skala. Lebih parah dari kekacauan manual, karena yang manual setidaknya mengumumkan dirinya.
Karena itu tidak bisa lompat ke pekerjaan AI yang menarik. Silo harus ditemukan, dipetakan, dikonsolidasikan dulu. Itu kerja fase pertama.
Fase 1: Current State Assessment
Tiap engagement mulai dari Current State Assessment. Minimum dua minggu. Tidak bisa diskip. Provider yang bilang bisa lebih cepat sedang merencanakan bangun yang salah.
Kamu tidak bisa mendesain sistem untuk operasi yang tidak kamu pahami. Tidak ada founder yang sepenuhnya paham operasinya sendiri. Itu bukan hinaan. Setiap bisnis punya dua peta. Founder's map: bagaimana bisnis seharusnya jalan. Floor map: bagaimana kerja benar-benar dikerjakan, termasuk workaround, spreadsheet tidak resmi, dan langkah ekstra karena sesuatu pecah di 2022. Sistem dari founder's map sulit diadopsi; tim merasakan mismatch-nya langsung. Sistem dari floor map dipakai, karena cocok dengan kerja yang terjadi.
Floor map tidak muncul sendiri. Harus diambil.
Wawancara
Wawancara 60 sampai 90 menit per orang, minimum satu orang per fungsi. Yang diwawancara orang yang mengerjakan kerjaan, bukan cuma yang mengelolanya. Ops manager dan koordinator di bawahnya akan deskripsikan proses yang sama secara berbeda. Versi koordinator yang akurat.
Bukan survei. Walkthrough. Pertanyaan intinya:
- Jalanin proses ini dari awal sampai akhir, termasuk langkah yang terasa terlalu kecil untuk disebut.
- Informasi datang dari mana waktu mulai, dikirim ke mana waktu selesai?
- Apa yang diketik atau disalin tangan lebih dari sekali?
- Kerja nunggu di mana, nunggu siapa?
- Apa yang dicek dua kali sebelum percaya angka di sistem?
- Workaround apa yang kamu bangun, yang resmi tidak ada yang tahu?
- Kalau volume dobel kuartal depan, apa yang pecah duluan?
Pertanyaan terakhir hampir selalu jawaban paling berharga. Orang tahu persis apa yang pecah duluan. Mereka kerja di samping kelemahan itu setiap hari. Kebanyakan, belum pernah ada yang tanya.
Setelah wawancara live, follow-up asinkron. Orang ingat detail penting dua hari kemudian: langkah yang terlupa, spreadsheet yang tidak disebut, atau pengecualian "hanya kadang-kadang" yang ternyata 20% kasus.
Inventaris silo
Paralel dengan wawancara, katalog setiap tempat data hidup. Tool, spreadsheet, folder shared drive, inbox yang diam-diam berfungsi sebagai database. Untuk masing-masing: isinya apa, siapa yang nulis, siapa yang baca, overlap-nya apa, biayanya berapa per bulan. Perusahaan kaget di dua angka: total tool biasanya 15 sampai 25, dan spend bulanan yang rutin masuk ribuan, dengan porsi berarti ke software yang dipakai satu orang atau tidak dipakai siapa-siapa.
Angka di bottleneck
Tiap bottleneck dikasih angka. Bukan rata-rata industri. Angka mereka, dari operasi mereka.
Jam per minggu untuk kerja manual, dikali loaded cost orang yang mengerjakannya, dikali 52: biaya tenaga tahunan. Ditambah sisi error (biaya satu kesalahan dikali seberapa sering), dan sisi throughput (deal yang macet, proyek telat, kapasitas yang tidak bisa diambil).
Begitu bottleneck punya angka dolar yang terverifikasi, prioritas berhenti jadi debat. Leadership lihat satu re-entry loop menghabiskan $40.000 per tahun di tenaga kerja, percakapan "perbaiki yang mana dulu" biasanya selesai sendiri.
Blueprint
Deliverable assessment: satu dokumen, berurutan. Peta proses current state visual (setiap langkah dan handoff), inventaris silo, daftar rasa sakit yang sudah diangkakan, peluang automation dan AI diurutkan ROI terproyeksi lawan kompleksitas build, arsitektur future state, rencana implementasi bertahap dengan rentang budget.
Urutan lebih penting dari daftar mentah. Menghasilkan 40 ide automation gampang. Nilainya: tahu yang mana 6 yang penting, yang mana 3 datang duluan, yang mana 10 kedengarannya keren tapi return-nya kecil.
Dua hal di fase ini lebih penting dari dokumennya.
Pertama, perusahaan melihat operasinya sendiri dengan jernih, sering untuk pertama kali. Sedikit sekali eksekutif yang pernah lihat peta visual cara bisnisnya benar-benar jalan. Reaksi hampir selalu versi ini: "Saya tidak sadar kita kerjanya begitu." Momen itu sendiri sering menutup biaya assessment.
Kedua, engagement signal. Cara perusahaan bersikap selama assessment adalah cara mereka akan bersikap selama build. Sinyal kuat: stakeholder datang wawancara siap, follow-up dijawab dalam sehari, orang menawarkan pain point tanpa diminta. Sinyal lemah: wawancara dijadwal ulang, jawaban satu baris, founder mau lompat ke demo. Sinyal lemah mereka perlakukan sebagai disqualifier. Engagement di assessment prediktor terbaik apakah yang dibangun akan diadopsi. Perusahaan yang anggap assessment formalitas akan biarkan sistem $50.000 duduk tidak terpakai, seberapa bagus pun engineering-nya.
Satu catatan lagi. Provider yang tawarkan audit bisnis dalam satu call 45 menit sedang kasih sales pitch. Assessment operasi yang berarti tidak selesai di jendela itu. Minimum dua minggu ada karena wawancara, follow-up, dan pemetaan memang butuh waktu itu.
Fase 2: arsitektur di kertas dulu
Setelah current state terpetakan, future state didesain utuh di kertas, sebelum apa pun dibangun. Di sini implementasi dimenangkan atau kalah. Fase yang paling banyak diskip provider, karena arsitektur kerja yang tidak kelihatan, yang tidak pernah di-screenshot. Bedanya: sistem yang tahan tiga tahun atau lebih, versus yang pelan-pelan rusak dalam beberapa bulan.
Schema dulu
Sebelum layar, sebelum automations, sebelum agents: schema. Entitas inti bisnis (klien, proyek, order, job, properti, pasien), field masing-masing, relasinya.
Lalu aturan yang menghapus silo secara permanen: one write path per entitas. Setiap data punya tepat satu tempat dilahirkan dan satu jalur di-update. Sisanya baca dari situ. Begitu dua sistem bisa nulis record yang sama, kamu membangun ulang masalah yang baru saja kamu bayar untuk selesaikan, cuma di software lebih baru.
Automations, agents, manusia
Nambah AI tanpa pilih adalah pola gagal yang umum. Setiap potongan kerja di future state masuk salah satu dari tiga.
Kerja deterministic dapat automation. Aturan bisa ditulis lengkap ("form masuk, buat record, assign owner, notify channel") tidak butuh AI. Nambah AI di situ cuma nambah biaya dan ketidakpastian ke sesuatu yang harus jalan identik setiap kali.
Kerja judgment dapat agent. Baca email masuk, tentukan jenis request; draft dokumen dari context; jawab pertanyaan ke knowledge base. Interpretasi atau generasi.
Kerja decision tetap di manusia, sistem yang menyiapkan. Setujui quote, terima klien, harga pengecualian: keputusan manusia. Sistem merakit semua yang dibutuhkan, jadi riset 40 menit jadi review 1 menit.
Porsi berarti dari yang perusahaan kira butuh AI ternyata deterministic. Temuan itu sendiri sering memotong sepertiga kompleksitas build yang diproyeksikan.
Absorb, keep, kill
Implementasi sering disalahpahami sebagai bangun dari nol. Bukan. Setiap tool dan proses dari inventaris silo masuk decision tree tiga cabang.
Absorb. Tool melakukan fungsi yang sistem baru harus miliki. Fungsi itu dibangun ulang ke operating system, tool-nya dibatalkan. Tool project management, form builder, tracker internal, add-on reporting, software yang dibeli untuk nutup celah. Di sini sebagian besar penghematan konsolidasi SaaS.
Keep. Tool memang unggul di kerjanya, lebih layak disambungkan daripada diganti. Software akuntansi hampir selalu tinggal. Email, kalender, sistem industri yang bawa bobot regulasi. Operating system jadi lapisan yang bikin mereka berperilaku seperti satu sistem.
Kill. Redundan, hampir tidak dipakai, atau menduplikasi yang lain. Dibatalkan, tidak perlu dibangun ulang. Biasanya tidak ada yang notice.
Jalankan setiap tool lewat pohon itu, scope build-nya hampir selesai sendiri. Perusahaan datang mengira rebuild habis-habisan, pulang lega: implementasi yang didesain baik menghapus lebih banyak daripada yang ia ciptakan.
Sequencing berpintu
Rencana build adalah fase-fase berpintu (gated). Tiap fase punya standar selesai. Fase berikutnya tidak mulai sebelum yang sebelumnya ketemu standar itu. Database tidak dikasih automations sebelum schema stabil. Agents tidak live sebelum workflow yang mereka andalkan jalan bersih. Di kertas kelihatan lebih lambat. Di praktik jauh lebih cepat, karena tim tidak pernah bangun di atas sesuatu yang masih bergerak.
Fase 3: build
Prinsip dari lebih dari 90 implementasi. Tidak ditekuk.
Fondasi dulu. Minggu-minggu awal milik database: tabel, relasi, permission, view, single source of truth. Bagian paling tidak impresif secara visual, paling penting, karena sisanya bergantung di situ. Klien wajar ingin lihat agents di minggu satu. Sistem yang tahan lama mulai dari schema di minggu satu.
Workflows sebelum intelligence. Automations menyusul database: intake, routing, approval, notifikasi, perubahan status. Pipa yang memindahkan informasi tanpa manusia. Agents terakhir, di atas workflow bersih dan data bersih. Agent yang baca database terstruktur dengan workflow terdefinisi, andal. Agent yang sama di atas operasi berantakan: output fasih dari informasi tidak lengkap.
Aturan one write path ditegakkan di kode. Setiap automation yang nulis data divalidasi ke schema. Data buruk ditolak di pintu masuk, bukan ketemu dan dibersihkan waktu reporting.
Progress kelihatan setiap hari. Channel bersama, klien lihat demonstrasi yang jalan tiap hari: form yang berfungsi, view baru, automation di data tes sungguhan. Barang yang kerja, bukan status update. Itu yang memotong mode gagal agensi klasik: klien bayar, sunyi enam minggu, lalu big reveal yang meleset. Klien nonton sistem tumbuh harian, koreksi dalam jam, kepercayaan menumpuk sepanjang proyek.
Check-in berstruktur. Di atas demo harian, call terjadwal: persiapan internal dulu, agenda sehari sebelumnya, call live (recap, demonstrasi, feedback, next steps), ringkasan tertulis hari itu dengan keputusan dan owner. Berulang dengan sengaja. Itu sebagian besar alasan klien percaya untuk departemen berikutnya setelah yang pertama ship.
Semua dibangun untuk handoff. Sistem dikonstruksi dan didokumentasi seolah orang lain akan mengelolanya besok. Naming convention yang orang asing bisa ikuti. Dokumentasi untuk karyawan baru. Panduan administrator. Langkah troubleshooting. Sistem yang cuma jalan karena pembangunnya tetap on call, tidak dibangun dengan benar.
QA di kondisi realistis, empat kategori. Integritas teknis: workflow, trigger, permission melakukan yang diklaim. Edge cases: data hilang, format jelek, duplikat, input aneh, lonjakan volume. User experience: anggota tim biasa bisa mengoperasikan tanpa dokumentasi terbuka di tab lain. Perilaku AI: output agent konsisten, akurat, terstruktur, diverifikasi ke test set sebelum kerja sungguhan bergantung padanya. Sistem jarang gagal di kondisi normal. Kondisi tidak biasa yang diuji.
Migrasi: yang semua orang pikir berlebihan
Pindah dari cara lama ke cara baru. Transisi ini mengakhiri lebih banyak implementasi daripada masalah teknis mana pun. Dua arah gagal: migrasi penuh heroik yang tidak ada yang butuh, atau tidak pernah commit ke tanggal switch sampai dua sistem jalan selamanya.
Tiga jalur.
Migrasi penuh. Data historis dibersihkan, dipetakan ke struktur baru, di-backfill. Tim jalanin dua sistem paralel untuk jendela terdefinisi, biasanya seminggu, kerja sungguhan di sistem baru, yang lama jadi jaring pengaman. Lalu cutover bertanggal, akses read-only ke yang lama, pensiun. Tepat kalau data historis kritis operasional: riwayat klien yang tim support cek setiap hari, record kepatuhan, keuangan yang nyetir reporting. Paling mahal. Paling sering dipilih default, lebih sering daripada semestinya.
Tanggal cutover. Tidak ada migrasi massal. Pilih tanggal. Setiap proyek, klien, atau order baru dari tanggal itu hidup di sistem baru. Yang sudah jalan selesai di sistem lama, yang kemudian kosong sendiri lalu dibatalkan.
Angka bikin logikanya kelihatan. Misal proyek rata-rata 60 hari. Migrasi penuh berarti minggu-minggu membersihkan record lama, dan kamu bayar kerja itu untuk proyek yang akan tutup dalam dua bulan anyway. Tanggal cutover berarti dalam satu siklus proyek, sistem lama tidak pegang yang aktif, sistem baru pegang semuanya. Migrasi selesai sendiri sementara orang cuma kerja.
Hibrida. Yang kebanyakan perusahaan butuhkan. Data referensi pindah: klien, kontak, vendor, katalog, karena umur pakainya panjang. Riwayat transaksional tidak: proyek lama, tiket, order selesai di sistem lama atau diarsip read-only. Kontinuitas di tempat yang penting, tanpa backfill mahal di tempat yang tidak.
Dua variabel: seberapa panjang siklus kerja, dan seberapa sering tim benar-benar merujuk record historis di kerja harian. Siklus pendek plus lookup jarang: tanggal cutover. Record berumur panjang plus lookup harian: penuh atau hibrida. Diputuskan di fase arsitektur, tertulis, tidak diimprovisasi saat build sudah berjalan.
Dua aturan, jalur mana pun. Tanggal switch dikomunikasikan ke seluruh tim berminggu-minggu sebelumnya, training sebelum hari-H, tidak ada yang kaget masuk sistem baru Senin pagi. Tool lama benar-benar dibatalkan sesuai jadwal. Spreadsheet cadangan yang tetap hidup, dalam sebulan jadi sistem saingan.
Fase 4: Adoption Rate
Sistem yang tidak dipakai tidak ada harganya, seberapa bagus pun dibangun. Fase ini dapat ketelitian yang sama dengan build.
Handoff: walkthrough penuh dengan leadership, training per peran. Tim operasi dilatih workflow mereka, tim sales yang mereka. Tidak ada yang duduk dua jam di fitur yang tidak akan mereka sentuh. Sesi direkam, training selamat dari turnover. Dokumentasi dan panduan administrator mengasumsikan pembaca belum pernah lihat sistemnya.
Satu metrik di atas yang lain. Adoption Rate: porsi workflow yang terpetakan yang benar-benar jalan lewat sistem baru, tim kerja di dalamnya, bukan di sekitarnya.
Adopsi tinggi kelihatan. Data mengalir tanpa dikejar. Spreadsheet lama layu karena ditinggal. Yang paling penting: orang mulai percaya jawaban sistem. Ada pertanyaan soal klien atau proyek, cek sistem, akurat, cek lagi besok. Kepercayaan menumpuk begitu.
Adopsi rendah juga kelihatan, dan 30 hari pertama setelah launch waktu mengawasinya: shadow spreadsheet. Seseorang diam-diam jaga tracker lama sebagai asuransi. Tidak diurus, dalam satu kuartal spreadsheet bayangan jadi sistem sungguhan lagi, dan build jadi antarmuka mahal di atasnya. Setiap sistem bayangan adalah informasi diagnostik: orangnya kurang dilatih, atau sistemnya memang tidak handle kasusnya. Keduanya cepat selesai kalau ketemu di bulan pertama. Karena itu mereka tetap terlibat aktif sebulan setelah launch, nonton usage, bukan hilang sehari setelah training.
Adopsi rendah hampir selalu jejaknya ke hulu: assessment diskip atau dikebut. Sistem didesain dari asumsi cara bisnis jalan, bukan cara kerja yang terjadi. Tim merasakan mismatch, lalu belok. Engagement signal di Fase 1 berat karena itu: adopsi diputuskan di dua minggu pertama engagement, jauh sebelum handoff.
Adoption Rate tinggi, ROI mengurus dirinya sendiri.
Fase 5: hidup setelah launch
Operating system makhluk hidup. Bisnis berubah, volume naik, edge cases muncul, tim berganti. Sistem harus ikut. Fase ini yang memisahkan sistem yang tahan tiga tahun atau lebih dari yang pelan-pelan rusak.
Empat feedback loop.
Data usage. Sistem log semuanya. Workflow mana yang bersih, mana yang error, fitur mana yang dipakai harian versus diabaikan. Fitur yang diabaikan juga informasi: apa pun yang tim belok, tidak cocok dengan cara mereka kerja. Data itu muncul jauh sebelum ada yang komplain. Usage sungguhan lebih andal daripada opini siapa pun soal sistem.
Error monitoring. Setiap automation nulis log. Gagal, gagalnya kelihatan: alert, manusia lihat, selesai, sering sebelum tim klien sadar. Yang berbahaya gagal sunyi: automation berhenti tiga minggu lalu, semua kira masih jalan. Sistem yang di-log dan dimonitor tidak menghasilkan gagal sunyi.
Siklus review. Terjadwal, bulanan atau kuartalan tergantung engagement. Agenda tetap: apa yang bersih, apa yang error, apa yang berubah di bisnis, apa yang harus dibangun berikutnya. Ekspansi lahir di sini. Sistem pertama membuktikan diri di satu departemen. Review adalah tempat departemen berikutnya, workflow berikutnya, agent berikutnya di-scope. Setiap akun multi-tahun mereka mulai dari satu build plus ritme review.
Feedback tim. Orang yang kerja di dalam sistem setiap hari merasakan gesekan sebelum dashboard mana pun. Channel tetap untuk laporkan gangguan kecil salah satu mekanisme return-nya paling tinggi di seluruh engagement. Iritasi kecil, dibetulkan cepat, yang jaga adopsi tinggi di bulan delapan, lama setelah energi launch pudar.
Satu hal yang mereka nyatakan polos: maintenance tidak dijual di hari satu. Kerja lanjutan didapat lewat hasil. Sistem live, adopsi naik, angkanya kelihatan, baru perusahaan tanya selanjutnya. Urutan itu yang penting. Provider yang dorong retainer besar sebelum deliver apa-apa sedang nunjukin di mana insentifnya duduk.
Lima pola gagal
Setelah 90+ build sendiri, plus post-mortem proyek provider lain, kegagalan mengelompok di lima pola.
Assessment diskip atau dilakukan dangkal. Sistem dari founder's map. Orang yang mengerjakan menolak. Adopsi tidak pernah terjadi. Penyebab paling umum. Diputuskan sebelum apa pun dibangun.
Proses yang rusak diotomasi. Workflow dasarnya tidak dibetulkan dulu. Sistem baru menjalankan disfungsi dengan kecepatan lebih tinggi.
Tool dipilih sebelum arsitektur ada. Software stack diputuskan dulu, bisnis dibengkokkan supaya cocok. Tool mestinya keputusan terakhir dalam urutan, bukan yang pertama.
AI masuk duluan, bukan terakhir. Agents ditaruh di data terfragmentasi, tanpa lapisan workflow di bawahnya. Demo mengesankan, kerja tidak andal, tim hilang iman ke seluruh inisiatif. Urutan operasi: data, lalu workflows, lalu intelligence.
Tidak ada yang punya switch. Tidak ada strategi migrasi, tidak ada tanggal cutover, tidak ada owner di sisi klien. Sistem baru launch ke ruang hampa, tool lama tetap hidup, inersia organisasi yang menyelesaikan sisanya.
Perhatikan: tidak satu pun dari lima itu teknis. Teknologinya belum pernah lebih mampu atau lebih mudah diakses. Implementasi gagal di proses, sequencing, dan adopsi. Karena itu prosesnya yang produk.
90 hari yang sebenarnya
Bentuk engagement tipikal. Timeline lentur dengan kompleksitas. Urutannya tidak.
Minggu 1 dan 2: Current State Assessment. Wawancara, inventaris silo, pemetaan workflow, kuantifikasi rasa sakit. Blueprint diantar dan di-walkthrough akhir minggu 2.
Minggu 3 dan 4: arsitektur dan fondasi. Data model difinalkan, decision tree diterapkan ke stack yang ada, jalur migrasi dipilih, build mulai dari database.
Minggu 5 sampai 8: workflows. Automations inti dibangun dan dites di data sungguhan, departemen per departemen, demonstrasi harian sepanjang itu.
Minggu 9 dan 10: lapisan intelligence. Agents di atas workflow yang sudah stabil, dites ke kasus sungguhan sebelum kerja sungguhan bergantung.
Minggu 11 dan 12: migrasi, training, launch. Switch di jalur yang dipilih, training per peran, tanggal cutover dihormati, tool lama dibatalkan.
30 hari pertama setelah launch: jaga adopsi. Usage dimonitor, sistem bayangan ketemu dan diselesaikan, gesekan diurus cepat. Dari situ engagement jalan di feedback loop: monitoring, review, optimasi, ekspansi.
Prosesnya yang produk
Siapa pun bisa bangun automation sekarang. Tool-nya belum pernah lebih baik. Barrier teknis belum pernah lebih rendah. Justru karena itu prosesnya lebih penting dari sebelumnya.
14 call itu tidak butuh orang yang hafal tool. Mereka butuh orang yang bisa assess seluruh operasi, temukan silo, angkakan rasa sakit, desain arsitektur, putuskan apa yang di-absorb, di-keep, di-kill, bangun dengan urutan benar, migrasi dengan cara benar, dan tetap accountable ke Adoption Rate lama setelah launch. Itu kerja sungguhannya. Kodenya bagian terkecil.
Dari silo sampai 90 hari
Enam slide. Dari kekacauan silo sampai cetak biru 90 hari.