Mengapa Organisasi Besar Selalu Memulai dari Business Architecture? Ini Alasan dan Cara Menerapkannya

Berapa langkah yang dibutuhkan untuk satu pengajuan cuti di organisasi Anda? Berapa kali data yang sama diinput ulang di aplikasi yang berbeda? Pegawai yang pernah mengalaminya mengerti bahwa masalahnya bukan di aplikasinya.

Organisasi terus membeli teknologi baru dengan harapan proses menjadi cepat. Proses lama yang usang, peran yang tidak jelas, dan aplikasi yang tumpang tindih tetap bertahan di baliknya.

Data industri mengonfirmasi pola ini. Riset BCG terhadap 825 eksekutif senior mencatat 70% transformasi digital gagal mencapai tujuannya, dan faktor penentunya justru dimensi organisasi: Proses Bisnis (SOP) dan budaya, bukan teknologinya (BCG, 2020). Gartner bahkan memproyeksikan lebih dari 70% implementasi ERP baru akan gagal memenuhi tujuan bisnis awalnya pada 2027 (Gartner, 2024).

Organisasi besar yang berhasil menghindari pola ini memulai dari titik yang berbeda: Business Architecture. Sebelum membahas alasannya, mari lihat dulu apa yang terjadi ketika organisasi melewatkannya.

Apa yang Terjadi Jika Organisasi Membangun Teknologi Tanpa Business Architecture?

Tanpa peta proses bisnis yang jelas, setiap unit membeli dan membangun aplikasi berdasarkan kebutuhan sesaat. Keputusan teknologi berjalan tanpa arah bersama.

1. Teknologi Hanya Memindahkan Kerumitan ke Layar yang Berbeda

Aplikasi baru mengotomatiskan proses lama apa adanya, termasuk seluruh kerumitannya. Proses yang bermasalah di atas kertas tetap bermasalah di dalam sistem.

Contohnya:

• Formulir kertas dengan lima tanda tangan berubah menjadi formulir digital dengan lima approval
• Data pelanggan diinput ulang di tiga aplikasi karena tidak ada yang memetakan alurnya
• Aplikasi workflow dibeli sebelum ada yang bertanya apakah alurnya masih relevan

Dampaknya:

• Waktu proses tidak berkurang meski investasi teknologi bertambah
• Pegawai mengeluh sistem baru lebih rumit dari cara lama
• Manajemen kehilangan kepercayaan pada inisiatif digital berikutnya

Investasi teknologi tanpa perbaikan proses menghasilkan kerumitan yang sama dengan biaya lebih mahal.

2. Setiap Unit Membangun Aplikasinya Sendiri Tanpa Koordinasi

Ketika tidak ada arsitektur yang menghubungkan kebutuhan antarunit, setiap divisi menyelesaikan masalahnya masing-masing. Portofolio aplikasi tumbuh liar.

Contohnya:

• Divisi keuangan dan divisi SDM membeli dua aplikasi berbeda untuk data pegawai yang sama
• Tiga unit menggunakan tiga format laporan untuk KPI yang seharusnya identik
• Integrasi antarsistem dikerjakan belakangan dengan biaya yang membengkak

Dampaknya:

• Data yang sama tersimpan di banyak tempat dengan versi yang saling bertentangan
• Biaya lisensi dan pemeliharaan membengkak untuk fungsi yang tumpang tindih
• Laporan lintas unit membutuhkan rekonsiliasi manual berhari-hari

Tim TI akhirnya menghabiskan energi menambal integrasi, bukan membangun kapabilitas baru.

3. Tidak Ada yang Tahu Siapa Berwenang Mengubah Apa

Proses bisnis berubah setiap saat: regulasi baru, restrukturisasi, produk baru. Tanpa peran yang jelas, perubahan berjalan tanpa kendali atau berhenti sama sekali.

Contohnya:

• Kepala unit mengubah alur kerja tanpa memeriksa dampaknya ke unit lain
• Dokumentasi proses tidak diperbarui karena tidak ada yang merasa memilikinya
• Usulan perbaikan dari pegawai lapangan tidak punya jalur resmi untuk diajukan

Dampaknya:

• Dokumentasi arsitektur usang dalam hitungan bulan setelah proyek selesai
• Perubahan lokal di satu unit merusak proses di unit lain tanpa disadari
• Audit dan kepatuhan regulasi menjadi pekerjaan panik menjelang tenggat

Ketiga masalah ini punya satu akar yang sama: organisasi membangun teknologi sebelum memahami bisnisnya sendiri. Solusinya dimulai dari Business Architecture.

Apa Itu Business Architecture?

Business Architecture adalah domain dalam Enterprise Architecture yang memetakan strategi, proses bisnis, peran, KPI, risiko, dan regulasi organisasi sebagai fondasi bagi keputusan data, aplikasi, dan teknologi. Domain ini menjawab pertanyaan “bagaimana organisasi bekerja” sebelum organisasi memutuskan “teknologi apa yang dibutuhkan”.

John Zachman meletakkan dasar pemikiran arsitektur enterprise melalui Zachman Framework pada 1987, kemudian The Open Group mengembangkannya menjadi metodologi praktis melalui The TOGAF Standard, yang kini mencapai edisi ke-10 (The Open Group, 2022). TOGAF menempatkan Business Architecture sebagai fase pertama pengembangan arsitektur, sebelum arsitektur data, aplikasi, dan teknologi.

Urutan ini bukan formalitas. Business Architecture memastikan tiga hal: teknologi dibangun untuk proses yang benar, setiap unit bekerja dari peta yang sama, dan setiap perubahan punya pemilik yang jelas.

Langkah Praktis Memulai Enterprise Architecture dari Business Architecture

Organisasi tidak perlu memetakan semuanya sekaligus. Mulai dari proses yang paling bermasalah, bangun tata kelolanya, lalu perluas.

1. Petakan Proses Bisnis Inti Beserta KPI, Risiko, dan Regulasinya

Pilih 3–5 proses bisnis yang paling sering dikeluhkan atau paling berdampak ke pelanggan. Modelkan alurnya dengan BPMN, lalu hubungkan setiap proses ke KPI yang mengukurnya, risiko yang menyertainya, dan regulasi yang mengikatnya.

Pemetaan awal ini langsung memperlihatkan celah: proses tanpa KPI, risiko tanpa mitigasi, atau alur yang melewati lebih banyak langkah dari yang diperlukan.

2. Tetapkan Process Owner dan Pengelola Arsitektur dengan KPI yang Terukur

Setiap proses inti membutuhkan satu pemilik yang berwenang mengusulkan perubahan, dan organisasi membutuhkan pengelola arsitektur yang meninjau konsistensi setiap usulan. Lengkapi kedua peran dengan KPI, misalnya kelengkapan dokumentasi dan waktu tinjau usulan.

Peran tanpa KPI cepat terlupakan begitu kesibukan operasional datang.

3. Integrasikan Siklus Perubahan Artefak ke Rutinitas Organisasi

Bangun alur baku: Process Owner mengajukan perubahan, pengelola arsitektur meninjau dan menyetujui, tim memperbarui artefak, lalu pengelola menyosialisasikan hasilnya. Jadwalkan tinjauan artefak secara berkala, misalnya per kuartal, dan sertakan pendampingan agar pegawai memahami standar pemodelan.

Siklus inilah yang membedakan EA sebagai praktik hidup dari EA sebagai proyek dokumentasi sekali jadi.

4. Gunakan Model Kematangan sebagai Peta Perjalanan

Ukur posisi organisasi pada lima tingkat kematangan: awal (ad hoc), berkembang (kebijakan dan peran mulai ditetapkan), terdefinisi (artefak dan standar konsisten), terkelola (EA dipakai mengukur kinerja), dan optimal (EA mendukung perbaikan berkelanjutan). Tetapkan target realistis satu tingkat per periode.

Organisasi yang mencoba melompat langsung ke tingkat optimal biasanya berhenti di dokumentasi yang tidak pernah dipakai. Kenaikan bertahap, seperti 2,1 ke 2,8 lalu 3,2 pada studi kasus di atas, jauh lebih bertahan.

5. Evaluasi Efektivitas dan Kematangan Secara Berkala

Jalankan survei efektivitas (administrasi, perencanaan, metode, artefak, integrasi, kelincahan, keselarasan) dan survei kematangan (pengembangan arsitektur, hubungan bisnis, keterlibatan pimpinan, partisipasi unit, komunikasi, keamanan, tata kelola) minimal setahun sekali. Jadikan hasilnya bahan perbaikan periode berikutnya, termasuk untuk mendeteksi sinyal pelemahan sejak dini: komitmen pimpinan yang menurun, pergantian pengelola yang terlalu cepat, atau akses yang terlalu dibatasi sehingga unit berhenti berpartisipasi.

Pengukuran rutin mengubah EA dari keyakinan menjadi bukti.

Kesimpulan

Organisasi besar memulai dari Business Architecture karena teknologi tidak pernah memperbaiki proses yang salah. Teknologi hanya mempercepatnya.

Tanpa Business Architecture:

• Aplikasi baru mengotomatiskan kerumitan lama dengan biaya lebih mahal
• Setiap unit membangun solusinya sendiri hingga portofolio aplikasi tumpang tindih
• Perubahan proses berjalan tanpa kendali karena tidak ada pemilik yang jelas

Business Architecture memberi organisasi peta proses, peran, KPI, risiko, dan regulasi sebagai fondasi seluruh keputusan teknologi. Tata kelola yang berjalan rutin kemudian menjaga peta itu tetap relevan setelah proyek pengembangan selesai.

The Open Group menetapkan urutan ini dalam The TOGAF Standard edisi ke-10, dan organisasi-organisasi di Indonesia telah membuktikannya melalui penerapan yang terukur. Pendekatan yang sama menjadi bagian dari framework idEA (integrated multidimensional Enterprise Architecture) yang dikembangkan Brainmatics.

Ingin Membangun Enterprise Architecture Secara Profesional?

Jika Brainers ingin memulai penerapan Enterprise Architecture yang terarah dari fondasi bisnisnya, pelajari melalui course Enterprise Architecture Fundamentals dari Brainmatics.

Pada kursus ini, Brainers akan mempelajari:

• Konsep dan metodologi Enterprise Architecture mengacu pada The TOGAF Standard dan idEA
• Business Architecture: pemetaan strategi, proses bisnis, KPI, risiko, dan regulasi
• Pemodelan proses bisnis menggunakan notasi BPMN pada Sparx Enterprise Architect
• Arsitektur data, aplikasi, dan teknologi beserta hubungan antardomainnya
• Perencanaan implementasi dan tata kelola arsitektur melalui studi kasus organisasi nyata

Hubungi Learning Advisor kami sekarang untuk konsultasi mengenai jadwal dan detail kursus

Sumber Data & Referensi

• The Open Group. The TOGAF Standard, 10th Edition. The Open Group, 2022.
• Bonnet, Marc J. A. Measuring the Effectiveness of Enterprise Architecture Implementation. Delft University of Technology, 2009.
• Kassa, Ermias Abebe, dan Jan C. Mentz. “Towards a Human Capabilities Conscious Enterprise Architecture.” Information, 12(8), 327, 2021.
• Banaeianjahromi, Negin, dan Kari Smolander. “Lack of Communication and Collaboration in Enterprise Architecture Development.” Information Systems Frontiers, 21, 2019.
• Gong, Yiwei, dan Marijn Janssen. “Exploring Causal Factors Influencing Enterprise Architecture Failure.” IFIP TDIT, 2020.