Saat ini hanya menerima 3 klien baru per bulan
How I Work

Saya Tidak Memulai dari Solusi.
Saya Memulai dari Keputusan yang Sebenarnya Terjadi.

Ketika sebuah organisasi mengalami keputusan yang lambat, terlalu banyak approval, manager yang ragu bertindak, atau terlalu banyak hal yang kembali kepada owner, solusi pertama bukan selalu menambah SOP, orang, atau aturan.

Saya mulai dengan memahami bagaimana keputusan benar-benar bergerak di dalam organisasi lalu mencari di mana sistemnya mulai mengalami friction.

Diskusikan Situasi Anda Lihat Prosesnya

Karena Organisasi di Atas Kertas Tidak Selalu Sama dengan Praktik.

Organization chart menunjukkan siapa melapor kepada siapa dan SOP menunjukkan bagaimana proses seharusnya dikerjakan.

Tetapi keduanya belum tentu menunjukkan bagaimana keputusan dibuat ketika menghadapi situasi nyata, atau bahkan yang terjadi di lapangan tidak sama dengan yang di atur oleh kedua hal itu.

Siapa yang sebenarnya mengambil keputusan?
Di mana keputusan mulai tertahan?
Kapan seseorang memilih meminta approval?
Mengapa masalah tertentu selalu kembali kepada orang yang sama?
Dan kapan sebuah keputusan benar-benar perlu naik ke level yang lebih tinggi?

Pertanyaan-pertanyaan tersebut membawa saya dari struktur formal menuju real decision flow.

Karena sebelum memperbaiki sistem keputusan, kita perlu melihat sistem yang sebenarnya.

Saya Mengikuti Keputusan, Bukan Sekadar Struktur.

Saya tidak memulai dengan mengasumsikan bahwa saya sudah tahu masalahnya. Saya mulai dengan mengikuti keputusan tertentu dari awal sampai selesai. Dari sana saya melihat empat hal:

Lensa Framework untuk Membaca Sistem Keputusan

Lensa Framework untuk Membaca Sistem Keputusan

Saya membangun sebuah lensa framework untuk membaca sistem keputusan

Dari Cerita yang Terlihat Kusut Menjadi Gambaran yang Jelas.

Dari Cerita yang Terlihat Kusut Menjadi Gambaran yang Jelas.

Setiap engagement dapat berbeda dalam kedalaman dan durasinya. Tetapi cara saya berpikir mengikuti alur yang sama: memahami konteks, mengikuti keputusan, menemukan pola, mendiagnosis masalah, lalu menentukan apakah perubahan memang diperlukan.

01

Understand

— Memahami organisasi

Saya mulai dengan memahami bagaimana organisasi bekerja dari sudut pandang orang-orang di dalamnya. Bukan hanya struktur formal, tetapi juga bagaimana koordinasi berlangsung, siapa yang menjadi tempat bertanya, bagaimana keputusan biasanya dibuat, dan pola apa yang terus berulang.

  • Struktur formal & informal
  • Pola koordinasi
  • Leadership involvement
  • Dependency & recurring problems
  • Bagaimana orang menjelaskan masalahnya sendiri
Pertanyaan utama

Apa yang sebenarnya terjadi di organisasi ini?

Output: Organizational Reality
02

Trace

— Mengikuti keputusan nyata

Setelah konteks cukup jelas, saya memilih keputusan atau area keputusan yang relevan untuk ditelusuri. Saya mengikuti satu keputusan nyata dari awal sampai selesai. Bukan untuk mencatat semua keputusan di perusahaan, tetapi untuk menemukan keputusan yang dapat menunjukkan bagaimana sistem bekerja.

  • Approval pembelian
  • Keputusan produksi
  • Hiring
  • Perubahan permintaan customer
  • Keputusan lintas divisi
  • Exception
  • Keputusan yang sering naik kepada owner
Pertanyaan utama

Kalau keputusan ini terjadi, apa yang sebenarnya terjadi dari awal sampai selesai?

Output: Decision Flow
03

Diagnose

— Menemukan pola

Di tahap ini saya tidak berhenti pada cerita seperti "manager tidak inisiatif", "approval terlalu lama", atau "owner terlalu banyak ikut campur". Saya mencari pola di balik cerita tersebut. Jika beberapa orang dari fungsi berbeda menceritakan masalah yang serupa, tetapi menyalahkan orang yang berbeda, kemungkinan masalahnya bukan sekadar individu.

  • Recurring pattern
  • Decision bottleneck
  • Authority gap
  • Escalation pattern
  • Friction lintas fungsi
Pertanyaan utama

Apa yang terus terjadi, dan apa yang membuatnya terus terjadi?

Output: Diagnosis
04

Frame

— Melihat masalah dari perspektif sistem

Tidak semua masalah yang terlihat sebagai masalah orang sebenarnya berasal dari orang. Saya membantu leadership melihat hubungan antara gejala bisnis dan sistem keputusan yang mendasarinya.

  • Memisahkan gejala dari pola
  • Menghubungkan masalah operasional dengan decision system
  • Menentukan masalah mana yang perlu diperbaiki terlebih dahulu
  • Membantu leadership melihat trade-off antara speed, control, dan accountability
Tujuan

Bukan sekadar mengetahui apa yang salah, tetapi memahami mengapa pola tersebut terus terjadi.

Output: Framing
05

Design

— Merancang perubahan jika diperlukan

Jika diagnosis menunjukkan bahwa masalah membutuhkan perubahan struktural, saya membantu merancang bagaimana sistem keputusan seharusnya bekerja.

  • Decision rights & authority boundaries
  • Decision ownership
  • Escalation rules
  • Exception handling
  • Governance & organizational guardrails
Prinsip

Tujuannya bukan mendorong semua keputusan ke bawah. Tujuannya adalah menempatkan setiap keputusan pada level yang tepat.

Output: Decision Architecture Blueprint
Diagnosis

Gejala Bukan Selalu Masalahnya.

"Tim saya tidak inisiatif." "Manager saya selalu minta approval." "Semua hal kembali ke saya." "Antar divisi susah bekerja sama." "Saya rasa kami butuh SOP baru." Semua itu bisa benar. Tetapi itu masih berupa gejala. Sebelum menentukan solusi, saya ingin mengetahui apa yang membuat pola tersebut terus terjadi.

"Manager tidak berani mengambil keputusan."
Mungkin bukan masalah keberanian. Bisa jadi decision authority tidak cukup jelas.
"Semua harus approval owner."
Mungkin bukan karena owner tidak percaya tim. Bisa jadi decision rights belum benar-benar berpindah.
"Antar divisi sering konflik."
Mungkin bukan sekadar masalah komunikasi. Bisa jadi ownership terhadap keputusan lintas fungsi tidak jelas.
"Kami butuh SOP."
SOP mungkin membantu. Tetapi jika decision boundary belum jelas, SOP baru belum tentu menyelesaikan akar masalah.
Real Example

Seperti Apa Prosesnya di Dalam Proyek?

Contoh sederhana dari sebuah engagement:

Leadership Menceritakan Masalahnya

"Manager saya sebenarnya bagus, tapi hampir semua keputusan tetap kembali ke saya."

Saya tidak langsung menyimpulkan "Masalahnya delegation." Saya mulai bertanya: "Bisa ceritakan keputusan terakhir yang kembali kepada Anda?"

Kita Mengikuti Satu Keputusan Nyata

Misalnya keputusan pembelian.

Request → Supervisor → Purchasing → Manager → Owner → Purchasing

Keputusan sebenarnya bisa berhenti di Manager, tetapi Manager tidak yakin apakah ia memiliki authority untuk mengambil keputusan tersebut.

Kita Mencari Pola

Kasus serupa ditemukan pada purchasing, hiring, customer request, dan operational exception.

Bukan empat masalah berbeda. Ada satu pola: Decision authority belum benar-benar berpindah meskipun struktur organisasi sudah bertambah.

Kita Mendiagnosis

Formal responsibility sudah ada, tetapi real decision authority belum cukup jelas untuk membuat keputusan berhenti di level tersebut.

Kita Menentukan Apa yang Perlu Berubah

Baru kemudian dibahas: apakah authority perlu diperjelas, apakah escalation rule perlu diperbaiki, apakah decision rights perlu dirancang, atau apakah perlu redesign yang lebih luas.

Tidak Semua Hal yang Penting Ada di Data.

Tidak Semua Hal yang Penting Ada di Data.

Sebagian informasi paling penting dalam diagnosis organisasi tidak selalu muncul dalam spreadsheet atau organization chart.

7 Kemampuan Manusiawi Decision Architect

Observation — Melihat sinyal yang sering tidak muncul dalam data. Pattern Recognition — Menghubungkan cerita yang tampak terpisah. Diagnosis — Membedakan gejala dengan akar masalah. Judgment — Menentukan insight mana yang benar-benar penting. Framing — Membantu leadership melihat masalah dari sudut yang lebih tepat. Synthesis — Mengubah informasi yang tersebar menjadi gambaran yang jelas. Executive Communication — Menyampaikan insight yang mungkin sulit diterima tanpa kehilangan kejelasan.

Yang Tidak Selalu Terlihat dalam Data:

Cara seseorang menjawab.
Hal yang tidak dikatakan.
Perbedaan cerita antara leadership dan tim.
Siapa yang selalu menjadi tempat bertanya.
Siapa yang sebenarnya memiliki pengaruh meskipun tidak memiliki posisi formal.
Dan bagaimana orang bereaksi ketika membicarakan sebuah keputusan.

Teknologi dan AI dapat membantu pekerjaan mekanis. Tetapi judgment terhadap konteks, dinamika manusia, dan keputusan yang tepat tetap menjadi bagian manusia dari pekerjaan ini.

Validation

Saya Tidak Menganggap Hipotesis Pertama Sebagai Jawaban.

Diagnosis yang baik bukan tentang seberapa cepat saya menemukan jawaban. Justru sebaliknya. Setelah menemukan pola awal, saya mencari bukti yang dapat mengonfirmasi maupun membantahnya.

Observation
Pattern
Hypothesis
Validation
Diagnosis

Tujuannya bukan membuktikan bahwa hipotesis saya benar. Tujuannya adalah memastikan diagnosis cukup kuat untuk digunakan sebagai dasar keputusan.

Maturity

Tidak Semua Organisasi Membutuhkan Kedalaman yang Sama.

Cara saya bekerja mengikuti kondisi organisasi. Saya tidak memaksakan istilah atau solusi yang belum relevan dengan tahap organisasi Anda.

Level 1

Founder-Centric

"Semua masih ke saya."

Owner Dependency
Level 2

Structured Growth

"Supervisor saya sering bingung."

Decision Bottleneck
Level 3

Mature Growth

"Keputusan antar fungsi mulai kompleks."

Decision Architecture
Level 4

Enterprise

"Bagaimana menjaga decision system tetap sehat?"

Decision Governance
Depth

Kedalaman Proses Menyesuaikan dengan Pertanyaan yang Perlu Dijawab.

Tidak semua organisasi perlu melewati seluruh tahap. Engagement berkembang berdasarkan apa yang ditemukan selama proses.

Diagnosis Apa yang sebenarnya terjadi?
Clarity Bagaimana sistem keputusan bekerja secara keseluruhan?
Redesign Apa yang perlu dirancang ulang?
Advisory Bagaimana menjaga perubahan tetap berjalan?
Boundary

Apa yang Tidak Saya Lakukan.

Saya tidak datang dengan template solusi yang sama untuk semua perusahaan.
Saya tidak langsung menyimpulkan masalah hanya dari organization chart.
Saya tidak menganggap semua masalah adalah masalah individu.
Saya tidak otomatis menyarankan SOP baru.
Saya tidak melakukan redesign sebelum memahami kondisi sebenarnya.
Saya bukan project manager operasional Anda.
Saya tidak mengambil alih keputusan leadership.
Saya tidak menjanjikan bahwa semua masalah dapat diselesaikan dengan satu framework.

Peran saya bukan mengambil alih keputusan Anda. Peran saya adalah membantu Anda melihat sistem keputusan dengan lebih jelas sehingga leadership dapat mengambil keputusan yang lebih tepat mengenai apa yang perlu diubah.

Outcome

Apa yang Anda Dapatkan dari Proses Ini.

Fokus pada perubahan pemahaman, bukan sekadar dokumen.

Clarity

Memahami apa yang sebenarnya terjadi.

Visibility

Melihat di mana keputusan tertahan.

Authority Clarity

Mengetahui siapa yang seharusnya dan sebenarnya memutuskan.

Prioritization

Mengetahui masalah mana yang paling layak diperhatikan.

Direction

Mengetahui langkah berikutnya tanpa harus langsung melakukan perubahan besar.

Anda tidak membeli template. Anda membeli clarity, judgment, dan arah keputusan.

Start Here

Anda Tidak Perlu Datang dengan Diagnosis.

Anda tidak perlu mengetahui istilah seperti Decision Architecture, decision rights, atau authority gap sebelum berbicara dengan saya. Cukup bawa satu situasi yang terasa mengganggu.

"Semua keputusan masih kembali kepada saya."
"Manager saya selalu minta approval."
"Produksi sering menunggu keputusan."
"Antar divisi sering saling lempar."
"Kalau saya tidak ada, banyak hal berhenti."
"Saya tidak tahu apakah struktur kami sudah cukup untuk berkembang."

Kita mulai dari situasinya. Diagnosis datang kemudian.

Ada Keputusan yang Terus Kembali ke Tempat yang Sama?

Tidak perlu menyiapkan diagnosis. Ceritakan satu keputusan, bottleneck, atau pola yang terus berulang di organisasi Anda. Dari sana kita dapat melihat apakah masalahnya memang berada pada decision system — dan apa langkah yang paling masuk akal berikutnya.

Bicarakan Situasi Anda Pelajari Decision Architecture