Ketika organisasi berkembang, bukan hanya jumlah orang dan proses yang bertambah. Jumlah keputusan juga bertambah. Lebih banyak orang terlibat. Lebih banyak approval muncul. Lebih banyak keputusan lintas fungsi. Lebih banyak masalah naik ke leadership.
Decision Architecture melihat lapisan di balik semua itu: siapa yang memutuskan, siapa yang memiliki authority, bagaimana keputusan bergerak, kapan harus dieskalasikan, dan di mana sistem keputusan mulai mengalami friction.
Tapi ini yang dirasakan:
Pertanyaan-pertanyaan tersebut terlihat seperti masalah yang berbeda.
Tetapi sebagian di antaranya dapat berasal dari lapisan yang sama: bagaimana sistem keputusan organisasi sebenarnya bekerja.
Ketika organisasi masih kecil, banyak keputusan dapat diselesaikan secara langsung oleh owner. Orang saling mengenal. Informasi relatif dekat. Struktur masih sederhana.
Ketika organisasi berkembang, kondisi berubah. Muncul supervisor, manager, department, multiple locations, multiple functions, customers with different requirements, higher financial exposure, dan lebih banyak operational dependencies.
Sistem keputusan yang dulu bekerja secara informal belum tentu tetap bekerja ketika kompleksitas meningkat.
Organisasi mungkin telah berkembang lebih cepat daripada sistem keputusannya.
Decision system adalah keseluruhan pola mengenai bagaimana keputusan dibuat, siapa yang terlibat, siapa yang memiliki authority, bagaimana informasi bergerak, kapan keputusan dieskalasikan, dan bagaimana keputusan tersebut dipertanggungjawabkan.
Ketika salah satu bagian tidak jelas, keputusan dapat mulai mengalami friction.
Decision Architecture adalah desain mengenai bagaimana keputusan, decision rights, authority, escalation, exception, accountability, dan governance bekerja bersama di dalam organisasi.
Decision Architecture bukan tentang membuat organization chart, SOP, RACI, delegation matrix, approval matrix, atau job description. Semua itu dapat menjadi bagian atau pendukung.
Tetapi pertanyaan utamanya adalah: Bagaimana keputusan benar-benar bergerak melalui organisasi?
Saya memeriksa bagaimana keputusan penting bergerak di dalam organisasi, di mana friction terjadi, siapa yang memiliki decision rights dan authority, bagaimana escalation berlangsung, dan apa yang perlu diperjelas agar keputusan terjadi pada level yang tepat.
Saya tidak mulai dengan "Mari kita buat RACI." Saya tidak langsung mulai dengan "Mari kita ubah organization chart." Saya mulai dengan: "Mari kita lihat bagaimana keputusan saat ini sebenarnya terjadi."
"Semua keputusan masih harus lewat saya."
"Semua menunggu approval."
"Manager saya tidak berani memutuskan."
"Sales dan Operations selalu saling menunggu."
"Hal-hal kecil terus naik ke direktur."
Apa yang terlihat seperti masalah orang kadang sebenarnya merupakan masalah sistem keputusan.
Tidak berarti masalah orang tidak pernah ada. Hanya saja, sebelum menyimpulkan bahwa orangnya adalah masalah, sistem yang membentuk perilaku tersebut layak diperiksa.
Organization chart menjelaskan siapa melapor kepada siapa. Tetapi organization chart tidak otomatis menjelaskan: siapa yang memutuskan, siapa yang dapat menolak keputusan, siapa yang harus approve, kapan keputusan harus naik, siapa yang menangani exception, dan apa yang terjadi ketika dua fungsi berbeda pendapat.
Structure menunjukkan reporting lines. Decision flow menunjukkan bagaimana organisasi sebenarnya bekerja.
Seseorang dapat memiliki responsibility tetapi tidak memiliki decision rights.
Manager bertanggung jawab terhadap hasil produksi. Tetapi ketika terjadi perubahan penting, ia tetap harus menunggu keputusan owner. Maka responsibility sudah berada di bawah. Tetapi decision right mungkin belum.
Authority gap terjadi ketika seseorang diharapkan bertanggung jawab terhadap suatu outcome tetapi tidak memiliki kewenangan yang cukup untuk mengambil keputusan yang diperlukan untuk menghasilkan outcome tersebut.
Semua keputusan harus melalui satu orang.
Secara formal manager memutuskan, tetapi secara praktik owner yang benar-benar memutuskan.
Tidak ada yang yakin: "Siapa sebenarnya yang boleh memutuskan?"
Escalation menjadi masalah ketika ia berubah dari mekanisme exception menjadi kebiasaan.
Keputusan apa yang memang harus dieskalasikan, dalam kondisi apa, dan kepada siapa?
Jika pola ini terus terjadi bahkan untuk keputusan yang sebenarnya dapat diselesaikan lebih rendah, maka pertanyaannya bukan sekadar "Kenapa manager tidak berani?" Tetapi: "Apa yang membuat sistem terus mengirim keputusan ke atas?"
Decision Architecture perlu melihat jenis keputusan yang berbeda.
Siapa boleh memutuskan perubahan di lapangan?
Approval apa yang sebenarnya diperlukan?
Siapa decision owner ketika dua fungsi terlibat?
Kapan masalah harus naik?
Keputusan apa yang memang harus tetap berada di leadership?
Siapa yang menangani kondisi yang tidak normal?
Siapa yang memutuskan masalah SDM?
Batas kewenangan finansial berada di mana?
Bagaimana leadership memastikan keputusan tetap berada dalam batas yang disepakati?
Ini bukan klasifikasi absolut. Ini adalah cara membaca seberapa kompleks sistem keputusan yang sedang dihadapi organisasi.
Saya tidak menentukan solusi sebelum memahami konteks aktual organisasi.
Memahami konteks organisasi.
Mengikuti bagaimana keputusan benar-benar bergerak.
Menemukan pola dan root problem.
Membantu leadership memahami masalah dengan cara yang lebih tepat.
Jika diperlukan, merancang sistem keputusan yang lebih sesuai.
Observe Before You Judge. Saya tidak langsung menyimpulkan "CEO terlalu controlling." Saya cari observasi: "Dalam 15 menit diskusi, CEO menjawab sebagian besar pertanyaan yang sebenarnya ditujukan kepada manager."
Tidak semua masalah membutuhkan redesign. Kadang masalah hanya terjadi pada satu decision cluster. Kadang masalahnya adalah authority. Kadang masalahnya adalah escalation. Kadang masalahnya memang membutuhkan redesign yang lebih luas.
Karena itu saya tidak menentukan solusi sebelum memahami konteks aktual organisasi.
Organization Design terutama membahas bagaimana organisasi disusun. Decision Architecture membahas bagaimana keputusan bekerja di dalam struktur tersebut.
Organization Chart: "Who reports to whom?" Decision Architecture: "Who decides what?"
RACI: "Who is Responsible, Accountable, Consulted, and Informed?" Decision Architecture: "Bagaimana decision rights, authority, flow, escalation, exception, dan governance bekerja sebagai sistem?"
Delegation: authority dipindahkan kepada orang lain. Decision Architecture: melihat bagaimana authority tersebut bekerja dalam sistem keputusan yang lebih luas.
SOP: bagaimana pekerjaan dilakukan. Decision Architecture: siapa yang memiliki hak memutuskan ketika pekerjaan tersebut membutuhkan judgment atau pilihan.
Governance: bagaimana organisasi diarahkan, dikontrol, dan diawasi. Decision Architecture: salah satu lapisan yang membantu menentukan bagaimana decision rights, authority, escalation, exception, dan accountability bekerja.
Disiplin-disiplin ini dapat saling melengkapi. Decision Architecture tidak dimaksudkan untuk menggantikan setiap bentuk organisational advisory lainnya.
Ini bukan tentang siapa yang salah. Ini tentang memahami apa yang sedang diproduksi oleh sistem.
Tujuannya bukan menghilangkan control. Tujuannya adalah menempatkan control pada level yang tepat.
Gejala-gejala tersebut bukan otomatis berarti Anda membutuhkan redesign. Tetapi semuanya dapat menjadi alasan yang baik untuk melihat decision system lebih dekat.
Pilih satu keputusan yang sering terlambat atau naik ke leadership. Kemudian tanyakan:
Jika beberapa jawaban tersebut sulit dijawab, mungkin ada bagian dari decision system yang belum cukup jelas.
Saya datang dari latar belakang teknologi dan software development. Pengalaman tersebut membentuk cara saya melihat sistem: flow, dependency, bottleneck, interface, dan apa yang terjadi ketika sebuah sistem menjadi semakin kompleks.
Hari ini saya membawa cara berpikir tersebut ke organisasi. Bukan untuk membangun software. Tetapi untuk memahami bagaimana keputusan bergerak di dalam organisasi.
Saya tidak menjual template. Saya membantu leadership melihat apa yang sebenarnya terjadi di dalam sistem keputusan mereka.
Jangan mendiagnosis orang sebelum memeriksa sistem yang membentuk perilakunya.
Melihat apa yang benar-benar terjadi.
Melihat pola yang muncul berulang.
Membedakan symptom dari underlying cause.
Menentukan insight mana yang paling penting.
Mengubah cara leadership melihat masalah.
Merangkai berbagai temuan menjadi satu cerita yang jelas.
Menyampaikan insight sehingga leadership dapat memahami dan bertindak.
Decision Architecture adalah complementary advisory layer. Bukan pengganti advisor fungsional.
Advisor lain mungkin membantu organisasi menyiapkan IPO dari sisi financial, legal, atau capital market. Decision Architect dapat melihat: siapa yang memiliki authority atas keputusan kritis, bagaimana escalation berjalan, dan apakah decision system siap menghadapi kompleksitas baru.
Tidak semua organisasi masuk dari Decision Architecture. Entry point disesuaikan dengan maturity dan masalah aktual.
Anda tidak perlu sudah mengetahui apakah masalah Anda adalah authority, delegation, decision bottleneck, atau escalation. Ceritakan situasinya. Kita mulai dengan memahami apa yang sebenarnya terjadi.