Dari Ide ke Arah Organisasi
Bagian ini membahas: Ketika Seseorang Ingin Menyelesaikan Sesuatu dengan Teknologi di Zaman AI; Menangkap Kebutuhan, Pengguna, dan Organisasi; Value, Biaya, AI Leverage, dan Return; Portfolio Inisiatif Lintas Fungsi; Quarterly Roadmap dan Delivery Confidence; Application Inventory, Building Block, dan Capability.
6 bab · 44 artikel
Bab 1: Ketika Seseorang Ingin Menyelesaikan Sesuatu dengan Teknologi di Zaman AI
membuka buku dari titik paling dekat: seseorang ingin menyelesaikan sesuatu dengan teknologi. Ia bisa sedang belajar, membangun usaha sendiri, membantu tim kecil, bekerja di startup, atau berada di organisasi besar. Ia belum harus memahami semua istilah teknis. Yang perlu ia lihat adalah bahwa di zaman AI, membuat code dan prototype menjadi lebih mudah, tetapi memahami apa yang layak dibuat tetap menjadi pekerjaan manusia.
Semua Berawal dari Ide atau Keluhan
Coba ingat kembali saat terakhir Anda ingin menyelesaikan sesuatu dengan teknologi. Mungkin Anda sedang mengelola tim kecil dan lelah meliha
Kenapa Code Terasa Seperti Pusat Segalanya
Setelah ide muncul, langkah berikutnya adalah memahami apa yang sebenarnya dibutuhkan, bukan langsung membuat solusi. Tapi coba perhatikan a
AI Membuat Prototype Cepat, Tapi Belum Tentu Berguna
Bayangkan Anda akhirnya memutuskan untuk bertindak. Ide sudah jelas: tim Anda butuh alat bantu untuk merekap data penjualan mingguan. Anda b
Bukan Cuma Membuat Baru: Memperbaiki, Merawat, dan Merombak
Pertanyaan 'layak dibuat' membawa kita ke pertanyaan yang lebih mendasar: untuk siapa solusi ini dan apa yang ingin diperbaiki? Tapi sebelum
Dari 'Saya Membuat Code' ke 'Saya Membantu Sesuatu Bekerja Lebih Baik'
Dengan berbagai kemungkinan tindakan ini, pertanyaan selanjutnya adalah: mana yang paling tepat? Jawabannya tergantung pada siapa yang akan
Pertanyaan Pertama: Untuk Siapa dan Memperbaiki Apa?
Perubahan identitas ini membawa kita ke pertanyaan paling penting yang harus diajukan di awal setiap inisiatif. Bukan "teknologi apa yang ak
Bab 2: Menangkap Kebutuhan, Pengguna, dan Organisasi
mengenalkan bahwa solusi yang baik dimulai dari pemahaman kebutuhan, pengguna, dan organisasi. Kebutuhan jarang datang sebagai dokumen rapi. Ia bisa muncul sebagai request, keluhan, chat singkat, contoh aplikasi lain, audit finding, pekerjaan berulang, atau proses yang terasa lambat. Pembaca diajak mengenal istilah satu per satu tanpa merasa sedang masuk kuliah teori.
Bukan Sekadar "Buatkan Fitur Ini"
Pagi itu, seorang product manager masuk ke ruang tim dengan semangat. "Kita perlu fitur export laporan ke PDF," katanya sambil meletakkan la
Dari Permintaan ke Alasan
Setelah kita tahu bahwa kebutuhan datang dalam berbagai bentuk, langkah selanjutnya adalah mengubah permintaan mentah itu menjadi alasan yan
Siapa yang Benar-Benar Memakai?
Setelah alasan perubahan jelas, kita perlu tahu siapa yang akan merasakan dampaknya—dan siapa yang sebenarnya menjadi pengguna solusi ini.
Pekerjaan yang Ingin Diselesaikan
Setelah kita tahu siapa penggunanya, langkah berikutnya adalah memahami pekerjaan apa yang sedang mereka coba selesaikan—bukan fitur apa yan
Organisasi sebagai Konteks
Pekerjaan pengguna tidak terjadi di ruang hampa. Ia terjadi di dalam organisasi yang punya proses, peran, aturan, dan batasan. Itulah kontek
Mengamati Alur Kerja, Bukan Menggambar Layar
Dengan memahami konteks organisasi, kita bisa mengamati alur kerja yang sebenarnya—bukan yang tertulis di dokumen prosedur.
Merangkum Temuan: Problem Statement dan Kriteria Keberhasilan
Setelah kita mengamati alur kerja, saatnya merangkum semua temuan menjadi satu dokumen yang menjadi pegangan bersama: problem statement, tuj
Bab 3: Value, Biaya, AI Leverage, dan Return
menjelaskan bahwa pekerjaan teknis layak dilakukan karena value, bukan karena terlihat sibuk. Value bisa berarti waktu lebih cepat, kesalahan turun, layanan membaik, keputusan lebih baik, capability meningkat, atau biaya per proses turun. AI masuk sebagai faktor perhitungan sejak awal karena dapat menurunkan effort dan cost per inisiatif, sehingga lebih banyak inisiatif menjadi feasible.
Pekerjaan Selesai, Tapi Apakah Ada Value?
Seorang kepala produk di perusahaan layanan digital bercerita kepada saya. Timnya menyelesaikan dua puluh fitur besar dalam satu kuartal. Sp
Value untuk Siapa Saja
Kepala produk itu bingung bukan karena fiturnya tidak selesai. Dia bingung karena setelah dua puluh fitur rilis, angka retensi pelanggan tid
Mengukur Value: Waktu, Biaya, Kesalahan, dan Keputusan
Kepala produk itu akhirnya duduk dengan timnya dan bertanya: “Kalau bukan jumlah fitur, apa yang seharusnya kita ukur?” Pertanyaan ini terde
Effort dan Biaya Sebelum dan Sesudah AI
Setelah value bisa diukur, kita perlu menghitung berapa effort dan biaya yang diperlukan untuk mewujudkannya. Kepala produk itu mulai menyad
AI Leverage: Bagian Mana yang Bisa Dipercepat
Kepala produk itu mulai melihat pola. Timnya menghabiskan banyak waktu pada aktivitas yang sebenarnya tidak membutuhkan judgment tinggi. Men
Return yang Praktis: Payback, ROI, dan Cost of Delay
Kepala produk itu sudah bisa mengukur value. Dia sudah tahu bagian mana dari pekerjaan timnya yang bisa mendapat leverage dari AI. Sekarang
Tiga Pola Organisasi: Native, Efisiensi, dan Diperlengkapi
Kepala produk itu mulai melihat sesuatu yang menarik. Di konferensi yang sama, dia bertemu dengan tiga jenis perusahaan yang semuanya memaka
Bab 4: Portfolio Inisiatif Lintas Fungsi
membahas cara menyusun portfolio inisiatif tahunan lintas organisasi. Portfolio tidak hanya berisi inisiatif IT. AI harus masuk ke proses filtering sejak awal karena dapat menurunkan effort dan biaya di operasi, finance, legal, HR, support, sales, marketing, risk, compliance, audit, product, knowledge management, dan IT. Tujuannya bukan mengurangi manusia, tetapi menaikkan kapasitas organisasi agar lebih banyak inisiatif bernilai bisa diambil.
Banyak Ide, Sedikit Tangan
Setiap awal tahun, organisasi Anda mengumpulkan usulan inisiatif dari berbagai fungsi. Marketing ingin membangun sistem personalisasi pelang
Melihat Organisasi dari Berbagai Lensa
Setelah kita sadar bahwa tidak semua ide bisa dikerjakan, kita perlu cara melihat organisasi dari berbagai lensa agar tidak melewatkan pelua
Menilai Value, Effort, dan AI-Adjusted Effort
Setelah kita punya daftar panjang kandidat, kita perlu cara membandingkannya secara objektif agar keputusan tidak hanya berdasarkan siapa ya
Kuadran Value vs Effort, dengan dan tanpa AI
Dengan nilai dan effort yang sudah dihitung, kita bisa memetakan inisiatif ke dalam kuadran untuk melihat mana yang paling menarik dikerjaka
Menyeimbangkan Jenis Pekerjaan dalam Portfolio
Setelah kita punya peta inisiatif, kita perlu memastikan portfolio tidak hanya berisi satu jenis pekerjaan saja. Ini masalah yang lebih umum
Capacity Planning Lintas Fungsi dan Stance Aman
Portfolio yang seimbang perlu didukung oleh kapasitas yang realistis, bukan hanya berdasarkan keinginan. Ini masalah yang saya temui hampir
Reskilling dan Pola Kerja Baru
Saya pernah melihat organisasi yang sudah menghitung ulang kapasitas mereka dengan AI-adjusted effort. Hasilnya menggembirakan. Tiba-tiba me
Annual Initiative Portfolio sebagai Output
Setelah melalui semua langkah sebelumnya—mengumpulkan kandidat dari berbagai lensa, menilai value dan effort, menyesuaikan dengan AI, memeta
Bab 5: Quarterly Roadmap dan Delivery Confidence
menjelaskan bahwa portfolio tahunan perlu dipecah menjadi roadmap per quarter. AI leverage dapat membuat beberapa inisiatif dimajukan, digabung, atau diperluas. Pembaca diajak melihat bahwa agresif bukan berarti ceroboh. Agresif berarti berani mengambil lebih banyak peluang dengan sequencing, readiness, verification, dan delivery keyakinan yang jelas.
Dari Portfolio Tahunan ke Empat Quarter
Bayangkan Anda baru saja menyelesaikan sesi portfolio planning bersama para kepala fungsi. Di atas meja ada dua belas inisiatif besar yang s
Menentukan Tema Setiap Quarter
Setelah portfolio tahunan dipecah menjadi empat quarter, pertanyaan berikutnya langsung muncul: inisiatif mana yang masuk ke quarter satu, m
Memecah Inisiatif Menjadi Stream
Bayangkan Anda sudah menetapkan tema quarter pertama: meningkatkan efisiensi operasional customer service dengan AI. Inisiatifnya sudah jela
Memetakan Dependency Lintas Fungsi
Stream tidak berjalan sendiri; mereka saling tergantung. Development stream mungkin sudah siap dengan kode chatbot, tetapi operation stream
Kapasitas yang Diperluas oleh AI
Setelah dependency terpetakan, langkah selanjutnya adalah menghitung kapasitas. Pertanyaannya sederhana: dengan jumlah orang yang sama, bera
Delivery Confidence: Agresif tapi Tidak Ceroboh
Kapasitas yang lebih besar memungkinkan kita lebih agresif, tetapi agresif perlu diimbangi dengan delivery keyakinan. Pertanyaannya: bagaima
Verification Gate dan Evidence-Based Review
Confidence perlu diuji dengan verification gate dan evidence, bukan sekadar perasaan. Bayangkan Anda sudah menetapkan bahwa sebuah inisiatif
Menyusun Satu Halaman Quarterly Roadmap
Setelah semua elemen tersusun—tema quarter, stream, dependency, kapasitas, delivery keyakinan, dan verification gate—pertanyaan berikutnya a
Bab 6: Application Inventory, Building Block, dan Capability
mengenalkan bahwa sebelum menentukan arah teknologi, organisasi perlu memahami apa yang sudah ada. Aplikasi, data, proses, dan integrasi tidak berdiri sendiri. Pembaca diajak melihat application inventory, application building block, dan capability sebagai cara membaca current state dan menentukan target state.
Kenapa Harus Tahu Apa yang Sudah Ada
Bayangkan ini: Anda baru bergabung sebagai arsitek di sebuah perusahaan yang sudah beroperasi lebih dari sepuluh tahun. Minggu pertama, tim
Data Minimum yang Harus Dikumpulkan
Setelah Anda mulai mendata aplikasi yang ada, pertanyaan berikutnya pasti muncul: data apa saja yang perlu dicatat? Banyak tim yang langsung
Membaca Siklus Hidup Aplikasi
Setelah data terkumpul, kita bisa mulai melihat siklus hidup setiap aplikasi. Anda akan menemukan bahwa tidak semua aplikasi dalam kondisi s
Membongkar Aplikasi Menjadi Building Block
Setelah tahu status aplikasi, kita perlu melihat lebih dalam: aplikasi terdiri dari apa saja.
Business Capability vs Technical Component
Setelah mengenal building block, kita perlu membedakan mana yang bersifat teknis dan mana yang merupakan kemampuan bisnis. Ini bukan sekadar
Memetakan Building Block ke Pengguna, Proses, dan Data
Setelah bisa membedakan keduanya, kita perlu memetakan building block ke konteks yang lebih luas. Sebuah building block tidak pernah berdiri
Capability: Apa yang Bisa Dilakukan Organisasi
Setelah peta building block tersusun, kita bisa melihat capability yang dimiliki dan yang belum dimiliki. Bayangkan Anda sedang berdiri di d
AI sebagai Asisten Inventarisasi dan Pemetaan
Anda sudah memetakan building block, melihat capability gap, dan mulai membayangkan target state. Sekarang muncul pertanyaan praktis: bagaim