🇬🇧 Read this article in English
Ringkasan Eksekutif
Arsitektur enterprise resource planning (ERP) lawas pada dasarnya tidak lagi sejalan dengan kecepatan bisnis modern. Ketika aplikasi keuangan konsumen dan korporat yang agile mampu menyelesaikan transaksi dan menyajikan data secara instan, sistem back-office tradisional masih terpaku pada pemrosesan batch dan antarmuka yang kaku. Dengan mempelajari disrupsi fintech pada sistem keuangan, para pemimpin IT dan keuangan perusahaan dapat beralih dari buku besar monolitik yang lambat ke arsitektur API-first dan composable yang mendukung pengambilan keputusan real-time serta kemampuan tutup buku berkelanjutan (continuous close).
Saat ini, hampir setiap diskusi tingkat direksi yang saya ikuti selalu berujung pada pembahasan AI generatif. Menyusul peluncuran ChatGPT yang fenomenal akhir tahun lalu, para eksekutif menuntut jawaban seberapa cepat kita bisa mengintegrasikan large language models (LLM) ke dalam operasi perusahaan. Namun, ketika saya melihat kondisi aktual infrastruktur backend di banyak organisasi, saya melihat ketimpangan yang mencolok. Perusahaan menginginkan AI mutakhir untuk memproses data keuangan mereka, tetapi data tersebut terjebak dalam ERP on-premise yang sangat dikustomisasi, atau ERP cloud hasil migrasi seadanya yang masih mengandalkan pemrosesan batch semalaman. Anda tidak bisa membangun lapisan kecerdasan buatan modern di atas arsitektur data era 1999. Inilah alasan mengapa gelombang disrupsi fintech pada sistem keuangan menjadi sangat krusial untuk dipahami. Teknologi keuangan B2B yang agile dan berfokus pada konsumen yang muncul selama dekade terakhir menawarkan pelajaran berharga dalam hal kelincahan arsitektur, aksesibilitas data, dan desain yang berpusat pada pengguna.
Selama dua dekade menavigasi persimpangan antara strategi IT dan operasi keuangan, saya telah menyaksikan semakin lebarnya jarak antara apa yang diberikan oleh perusahaan teknologi keuangan eksternal dan apa yang disediakan oleh departemen IT internal untuk tim akuntansi mereka. Perusahaan fintech tidak sukses semata-mata karena pemasaran yang lebih baik; mereka sukses karena memperlakukan data dengan cara yang berbeda. Mereka memperlakukan integrasi sebagai kompetensi inti, bukan sekadar renungan yang ditambahkan belakangan.
Jika perusahaan tradisional ingin bertahan menghadapi pergeseran teknologi saat ini—terutama dengan AI yang menuntut pipeline data real-time yang sangat terstruktur—mereka harus mengamati secara saksama bagaimana fintech beroperasi. Kita harus berhenti memandang startup yang lincah ini sekadar sebagai vendor atau hal baru, dan mulai memperlakukan mereka sebagai cetak biru arsitektur.
Elemen Inti Disrupsi Fintech pada Sistem Keuangan
Untuk memahami apa yang harus kita adaptasi, pertama-tama kita harus membedah mekanika kesuksesan fintech. Saat saya mengevaluasi aplikasi treasury modern atau startup manajemen pengeluaran, ada tiga prinsip arsitektur yang secara konsisten menonjol dibandingkan sistem ERP tradisional.
Arsitektur API-First vs. Integrasi Tambal Sulam
ERP tradisional dibangun sebagai sistem monolitik yang tertutup. Filosofinya sederhana: beli sistem kami, masukkan semua data Anda ke dalamnya, dan jangan pernah meninggalkannya. Ketika data eksternal dibutuhkan, data tersebut dipaksa masuk melalui middleware yang lamban atau transfer flat-file. Sebaliknya, fintech dibangun di atas arsitektur API-first. Mereka berasumsi sejak hari pertama bahwa mereka harus berkomunikasi dengan puluhan sistem eksternal—payment gateway, layanan verifikasi identitas, feed data pasar, dan sistem perbankan inti (core banking).
Dalam lingkungan API-first, integrasi bukanlah sebuah proyek; ini adalah fitur fundamental. Hal ini memungkinkan startup fintech untuk menyusun penawaran keuangan komprehensif dengan menghubungkan microservices terbaik di kelasnya (best-of-breed). Bagi IT perusahaan, pelajarannya jelas. Era ERP monolitik dari vendor tunggal sudah berakhir. Kita harus merancang sistem internal kita untuk mengekspos API internal yang aman dan terdokumentasi dengan baik, yang memungkinkan integrasi alat-alat baru secara cepat tanpa harus menunggu siklus upgrade vendor yang masif.
Event Streaming Real-Time vs. Pemrosesan Batch
Dengan latar belakang di bidang akuntansi, saya sangat memahami mengapa pemrosesan batch ada. Secara historis, daya komputasi sangat mahal, dan mengunci buku besar untuk menjalankan rekonsiliasi semalaman adalah satu-satunya cara untuk memastikan integritas data. Namun, komputasi tidak lagi menjadi hambatan. Hambatannya sekarang adalah arsitektur itu sendiri.
Fintech memanfaatkan arsitektur berbasis event (seperti Apache Kafka) di mana data bergerak sebagai aliran yang berkelanjutan (continuous streams). Saat transaksi terjadi, buku besar, model deteksi penipuan (fraud detection), dan antarmuka pengguna semuanya diperbarui secara bersamaan. Sistem keuangan tradisional masih sangat bergantung pada pemrosesan batch End-of-Day (EOD) atau End-of-Month (EOM). Baru-baru ini saya menasihati sebuah perusahaan manufaktur skala menengah di mana CFO-nya mengeluhkan visibilitas arus kas. Tim treasury mereka menggunakan aplikasi konsumen di ponsel yang bisa melakukan penyelesaian transaksi secara instan, namun mereka harus menunggu hingga Selasa pagi untuk melihat posisi kas hari Senin yang telah direkonsiliasi di dalam ERP bernilai miliaran rupiah mereka. Mengadopsi arsitektur event-streaming untuk jalur data kritis kini bukan lagi sekadar pilihan bagi perusahaan.
Alur Kerja Berpusat pada Pengguna vs Tampilan Database
Coba perhatikan antarmuka sistem keuangan lawas. Pada dasarnya, itu hanyalah pembungkus grafis dari sebuah relational database. Pengguna harus menyesuaikan diri dengan struktur database, memasukkan kode ke dalam puluhan kolom wajib hanya untuk memproses satu faktur sederhana. Aplikasi fintech mengabstraksi kompleksitas ini. Mereka memprioritaskan alur kerja dan niat pengguna, hanya meminta input yang benar-benar diperlukan dan menangani penataan data di latar belakang.
IT perusahaan harus berhenti memaksa staf akuntansi dan operasional menjadi administrator database. Memodernisasi sistem keuangan berarti berinvestasi pada pengalaman pengguna (user experience), seringkali dengan memisahkan lapisan presentasi (presentation layer) dari database inti.
Di Mana Lingkungan ERP Lawas Gagal Memenuhi Kebutuhan Perusahaan Modern
Memahami apa yang dilakukan dengan benar oleh fintech memaksa kita untuk menghadapi alasan mengapa sistem internal kita gagal. Penyebab utamanya adalah technical debt (utang teknis), khususnya dalam bentuk kustomisasi yang mendalam dan tidak dapat dikelola.
Selama dua puluh tahun terakhir, saya telah melihat banyak organisasi memodifikasi kode inti ERP mereka untuk mengakomodasi proses internal yang sangat spesifik—dan seringkali tidak efisien. Ketika teknologi baru muncul—seperti alat otomatisasi utang usaha (accounts payable) berbasis AI yang canggih—tim IT menyadari bahwa menghubungkannya ke ERP mereka yang rapuh dan sangat dikustomisasi akan membutuhkan proyek konsultasi yang masif. Ketakutan untuk menyentuh buku besar inti akhirnya melumpuhkan inovasi.
Lebih jauh lagi, ketergantungan pada satu vendor (vendor lock-in) membatasi kelincahan. Vendor ERP besar secara historis sering mengakuisisi startup inovatif dan mencoba memaksa mereka masuk ke dalam ekosistem lawas mereka, menghasilkan pengalaman yang kaku dan terputus-putus. Mereka menjual platform “terpadu” yang, pada kenyataannya, hanyalah tambal sulam hasil akuisisi yang disatukan oleh kode yang rapuh. Hal ini memperlambat kemampuan perusahaan untuk bereaksi terhadap perubahan pasar, membuat mereka rentan terhadap pesaing yang beroperasi dengan infrastruktur yang lebih lincah dan composable.
Kerangka Kerja untuk Memodernisasi Keuangan Perusahaan
Jika Anda seorang CIO atau CFO yang sedang melihat implementasi ERP yang sudah berusia lima tahun (atau lima belas tahun), Anda tidak bisa sekadar mencabut dan menggantinya. Gangguan bisnisnya akan menjadi bencana besar. Sebaliknya, kita harus menerapkan pendekatan modernisasi yang terstruktur dan bertahap, yang sangat dipengaruhi oleh kelincahan yang kita lihat di dunia fintech.
Langkah 1: Adopsi Strategi Aplikasi Pace-Layered
Gartner mengembangkan Pace-Layered Application Strategy bertahun-tahun yang lalu, dan ini tetap menjadi salah satu model mental paling efektif untuk tantangan ini. Kita harus membagi sistem kita ke dalam tiga kategori:
- Systems of Record: ERP inti dan buku besar (general ledger) Anda. Sistem ini harus berubah secara perlahan. Stabilitas dan kepatuhan adalah prioritas. Hapus kustomisasi dan kembalikan sistem ini ke konfigurasi standar bawaan pabrik (out-of-the-box).
- Systems of Differentiation: Aplikasi spesifik industri yang memberi Anda keunggulan kompetitif. Sistem ini berubah dengan kecepatan sedang.
- Systems of Innovation: Alat AI baru, lapisan pelaporan yang agile, dan aplikasi alur kerja cepat. Sistem ini harus berubah secara konstan.
Dengan melindungi System of Record dan mengekspos datanya melalui API yang aman, Anda dapat membangun Systems of Innovation yang lincah di atasnya, meniru arsitektur fintech tanpa mengambil risiko pada data keuangan inti Anda.
Langkah 2: Rangkul ERP yang Composable
Masa depan teknologi perusahaan adalah composable. Alih-alih membeli satu paket sistem besar dari satu vendor untuk menangani HR, Keuangan, Supply Chain, dan CRM, organisasi harus mengorkestrasi jaringan aplikasi terbaik di kelasnya. Gunakan platform integrasi modern sebagai layanan (iPaaS) untuk menghubungkan alat perencanaan cloud khusus, aplikasi manajemen pengeluaran terdedikasi, dan mesin penagihan yang agile kembali ke buku besar inti yang telah disederhanakan.
Langkah 3: Definisikan Ulang Tata Kelola IT untuk Integrasi Cepat
Saat kita beralih ke model composable yang digerakkan oleh API, tata kelola IT juga harus berevolusi. Model tata kelola lama berfokus pada kontrol ketat terhadap perangkat lunak apa yang boleh masuk ke dalam perusahaan. Model baru harus berfokus pada pengendalian bagaimana data mengalir antar sistem. Kita membutuhkan standar yang ketat untuk keamanan API, struktur payload data, dan manajemen identitas. Ketika tata kelola berfokus pada lapisan integrasi alih-alih lapisan aplikasi, unit bisnis mendapatkan kebebasan untuk menguji dan mengadopsi alat fintech baru dengan aman.
Dampak AI Generatif pada Ekosistem Keuangan
Kita tidak bisa membahas disrupsi hari ini tanpa menyinggung AI generatif. Large Language Models (LLM) memaksa akselerasi cepat dari tren yang telah saya uraikan di atas. Para pemimpin keuangan menuntut antarmuka percakapan (conversational interfaces) untuk data mereka. Mereka ingin mengetik, “Tunjukkan varians pengeluaran SaaS Eropa kita selama tiga kuartal terakhir, dengan mengisolasi fluktuasi mata uang,” dan menerima jawaban yang akurat secara instan.
Fintech saat ini berlomba-lomba membangun lapisan semantik ini. Mereka bisa melakukannya karena data mereka sudah terstruktur dengan rapi dan dapat diakses melalui API. Sebaliknya, perusahaan tradisional sedang kesulitan. Anda tidak bisa mengarahkan LLM ke relational database berusia dua puluh tahun yang berantakan dan penuh dengan tabel kustom, lalu mengharapkan jawaban yang koheren.
Mempersiapkan sistem keuangan Anda untuk AI berarti menyelesaikan pekerjaan normalisasi data yang seringkali tidak glamor. Ini membutuhkan transisi dari pemrosesan batch sehingga AI dapat menanyakan data secara real-time. Pola pikir fintech yang memperlakukan data sebagai aset yang dapat diakses dan cair adalah prasyarat mutlak untuk menerapkan AI generatif di perusahaan.
Langkah Konkret bagi CIO dan CFO
Strategi tanpa eksekusi hanyalah teori. Untuk mulai menerapkan prinsip-prinsip ini di organisasi Anda, pertimbangkan langkah-langkah konkret berikut:
- Audit Kesiapan API Anda: Minta tim arsitektur IT Anda untuk mengevaluasi kemampuan API dari sistem keuangan inti Anda saat ini. Jika ERP Anda utamanya mengandalkan transfer flat-file atau koneksi database langsung untuk data eksternal, memodernisasi lapisan integrasi tersebut harus menjadi prioritas.
- Identifikasi Satu Proses Batch untuk Dihilangkan: Temukan satu proses keuangan kritis yang saat ini berjalan semalaman—seperti rekonsiliasi inventaris atau pembaruan posisi kas—dan tugaskan tim lintas fungsi untuk mengubahnya menjadi streaming yang mendekati real-time. Gunakan ini sebagai percontohan untuk orkestrasi data modern.
- Pisahkan Pengalaman Pengguna: Jika tim akuntansi Anda kesulitan dengan antarmuka ERP yang kaku untuk tugas bervolume tinggi (seperti persetujuan faktur), jangan menunggu vendor untuk memperbarui UI mereka. Evaluasi alat front-end ringan berbasis API yang dapat terhubung ke buku besar Anda dan merampingkan alur kerja.
- Bentuk Dewan Tata Kelola Data AI: Satukan tim IT dan Keuangan sekarang. Sebelum ada departemen yang bertindak sendiri dan mengunggah data keuangan sensitif ke LLM publik, tetapkan kebijakan ketat tentang bagaimana AI generatif akan diuji dan diterapkan di dalam perimeter aman Anda.
Pertanyaan yang Sering Diajukan (FAQ)
Bagaimana perusahaan tradisional dapat menguji aplikasi fintech dengan aman?
Pendekatan paling aman adalah menciptakan lingkungan sandbox aman yang mencerminkan data produksi Anda tetapi sepenuhnya terputus dari sistem live Anda. Manfaatkan API gateway modern untuk mengontrol secara presisi data apa yang dapat diakses oleh aplikasi baru tersebut. Mulailah dengan proses non-kritis—seperti pelaporan pengeluaran karyawan atau onboarding vendor—sebelum mengintegrasikan fungsi treasury atau buku besar inti.
Apakah AI generatif akan menggantikan antarmuka ERP tradisional?
Dalam tiga hingga lima tahun ke depan, ya, untuk sebagian besar tugas analitis dan pelaporan standar. Daripada menavigasi struktur menu yang kompleks untuk menghasilkan laporan, para eksekutif dan manajer akan menggunakan perintah bahasa alami (natural language prompts). Namun, antarmuka transaksional yang mendasarinya, yang digunakan oleh profesional akuntansi untuk entri data yang sangat terstruktur, kemungkinan akan tetap ada, meskipun akan sangat terbantu oleh fitur auto-completion dan deteksi anomali berbasis AI.
Apa risiko terbesar saat mengintegrasikan alat fintech dengan sistem keuangan lawas?
Risiko utamanya adalah kegagalan dalam rekonsiliasi data. Ketika sistem real-time yang lincah mendorong data ke sistem lawas yang memproses secara batch, titik kegagalan akan berlipat ganda. Jika panggilan API gagal atau time out, sistem fintech mungkin mencatat transaksi sebagai selesai sementara ERP inti membuangnya. Tim IT harus merancang penanganan kesalahan (error-handling) yang kuat, skrip rekonsiliasi otomatis, dan mekanisme peringatan yang jelas pada lapisan integrasi.
Kesimpulan
Nilai sebenarnya dari menganalisis disrupsi fintech pada sistem keuangan tidak ditemukan dalam upaya mengubah perusahaan mapan menjadi startup yang lincah. Nilainya terletak pada mengadopsi filosofi arsitektur mereka. Fintech telah membuktikan bahwa perangkat lunak keuangan bisa menjadi intuitif, terintegrasi secara mendalam, dan mampu melakukan pemrosesan real-time.
Saat kita memasuki era yang didominasi oleh kecerdasan buatan dan tuntutan kecepatan data yang belum pernah terjadi sebelumnya, ERP monolitik tradisional adalah sebuah beban. Dengan beralih ke arsitektur composable, memprioritaskan API, dan menyingkirkan kustomisasi yang membatasi, para CIO dan CFO dapat membangun sistem keuangan yang tangguh. Tujuannya jelas: menciptakan infrastruktur di mana teknologi memungkinkan tutup buku berkelanjutan, memberikan visibilitas operasional instan, dan memberdayakan bisnis untuk beradaptasi lebih cepat daripada kompetitor.
