Apakah API merupakan Lego baru untuk membangun faktur elektronik dalam bisnis?

Apa persamaan Lego, API, dan e-faktur/tagihan elektronik? Mari kita mulai dengan API dan blok Lego. API yang bagus seperti balok Lego. Mereka mudah digunakan, dan mereka dapat digabungkan dengan cara baru dan inovatif yang melampaui tujuan yang dimaksudkan.

Sama seperti blok Lego, API dapat dimodifikasi, digabungkan, dan dirakit untuk membuat struktur baru. Misalnya, pada Gambar 1, Uber Eats memiliki API yang dapat digunakan restoran kecil untuk melihat data pesanan makan malam. Data ini kemudian dapat disimpan di Salesforce API untuk akuntansi akhir tahun keuangan.

Secara lebih teknis, application programming interfaces (juga dikenal sebagai API) dapat digunakan kembali, distandarisasi, dan dapat disesuaikan. Mereka memiliki komponen universal yang berfungsi sebagai blok penyusun, dengan instruksi yang membuatnya mudah digunakan, serta opsi untuk menggabungkan berbagai blok atau API untuk fungsi yang berbeda.

Instruksi ini didasarkan pada protokol. Pengembang/developer menggunakan protokol ini untuk hanya mengambil informasi yang diperlukan alih-alih mengembangkan seluruh aplikasi dari awal! Misalnya, pengembang bisa mendapatkan koordinat Google Maps tanpa perlu memahami bagaimana data dikumpulkan dari satelit dan citra historis.

Manfaat API – dan 2Cs

Meskipun API memiliki banyak manfaat luar biasa untuk bisnis, manfaat ini dapat dirangkum dalam 2C: customisation dan cost savings/Kustomisasi dan Penghematan Biaya.

Sama seperti kustomisasi balok Lego, pemilik bisnis dan tim pengembangannya dapat memilih fungsionalitas yang paling sesuai dengan kebutuhan bisnis mereka. Blok bangunan ini dapat mempercepat pengembangan aplikasi untuk bisnis dengan memanfaatkan kemampuan baru seperti API untuk menganalisis data, memantau titik kontak pelanggan, dan menghubungkan ke pemasok baru.

Untuk bisnis yang lebih kecil, API bisa memberikan peluang penghematan biaya. Alih-alih mengembangkan semua fungsionalitas dari awal atau membeli paket perangkat lunak yang memiliki banyak pilihan mewah yang tidak perlu, bisnis dapat mengintegrasikan kemampuan yang sesuai dengan anggaran mereka. Sebuah bisnis memiliki opsi untuk menyertakan atau mengecualikan Google API, misalnya, yang dapat menyebabkan perbedaan biaya yang besar.

Namun, tidak ada solusi “satu ukuran untuk semua” untuk mengembangkan aplikasi guna memecahkan masalah bisnis. API memberikan pertukaran yang seimbang antara kustomisasi dan efisiensi biaya. Pengembang memiliki cukup fleksibilitas untuk memilih fungsi API, tetapi mereka tidak akan dapat mengubah kode API di dalam API seperti halnya kita dapat memilih blok Lego untuk digunakan tetapi tidak dapat mengubah cara pembuatan Lego oleh Grup Lego.

E-Faktur

Profesor Fethi Rabhi dari Fakultas Ilmu dan Teknik Komputer di Universitas New South Wales dan Dr George Joukhadar, seorang dosen di Fakultas Sistem Informasi dan Manajemen Teknologi di Universitas New South Wales, telah berkolaborasi untuk melakukan penelitian interdisipliner mengenai penerapan ekosistem API di industri e-faktur. 

“Mulai 1 Juli, semua lembaga Pemerintah Australia mengaktifkan e-faktur,” kata Profesor Rabhi. Ini berarti bisnis yang melakukan transaksi dengan pemerintah Australia didorong untuk menyiapkan fasilitas e-faktur.

“Hal ini dapat dicapai dengan menerapkan spesifikasi BIS Billing 3.0. Spesifikasi ini ditopang oleh tiga pilar utama: format data, jaringan, dan validasi,” tambah Profesor Rabhi.

Format data memastikan interoperabilitas, yang memungkinkan informasi untuk dibaca oleh sistem yang berbeda. Misalnya, sistem faktur/tagihan penerima harus dapat membaca faktur dari sistem faktur pengirim. Ini dicapai melalui format terstandarisasi. Di Australia, format data yang diadopsi adalah Universal Business Language (UBL).

Jaringan, juga dikenal sebagai jaringan PEPPOL, adalah media pertukaran antara sistem pengirim dan sistem penerima yang memfasilitasi transfer data tagihan. Jaringan menghosting semua alamat bisnis digital dan, di Australia, hal ini didasarkan pada alamat ABN yang disetujui dari Kantor Perpajakan Australia (ATO).

Validasi adalah aturan yang diberlakukan oleh organisasi nirlaba atau badan pengatur. Di Australia, badan pengaturnya adalah ATO. Badan pengatur ini mengesahkan vendor yang menyediakan akses ke jaringan. Ini memastikan faktur diteruskan melalui jaringan dan mematuhi persyaratan peraturan.

Dengan meningkatnya persyaratan dari pemerintah internasional untuk mengimplementasikan PEPPOL, George menjelaskan bahwa “bergantung pada yurisdiksi negara, tidak semua tiga pilar perlu diimplementasikan. Di dalam pilar itu sendiri, mungkin ada variasi antar negara.”

Misalnya, perbedaan-perbedaan ini diamati dalam format data. Australia menggunakan format UBL sementara negara lain menggunakan format Cross Industry Invoice (CII). Dengan demikian, faktur di Australia tidak akan divalidasi dan diterima di jaringan lainnya.

Menerapkan ekosistem API ke e-faktur

Dengan adanya perbedaan persyaratan, analogi Lego API menjadi penting untuk memberikan kesempatan kepada bisnis dalam membangun sistem faktur elektronik dengan berbagai blok fungsionalitas. Hal ini telah menciptakan ekosistem API faktur elektronik yang terdiri dari tiga pemain utama: pelanggan, penyedia API, dan penyedia solusi.

Pelanggan adalah bisnis yang ingin membeli solusi bisnis, yang memungkinkan mereka untuk mengadopsi e-faktur sesuai dengan peraturan negara. Penyedia API adalah pengembang yang memahami persyaratan peraturan untuk membuat fungsi tertentu. Terakhir, penyedia solusi adalah perusahaan perantara yang menghubungkan penyedia API ke pelanggan dengan menyesuaikan solusi terpaket.

Pemodelan Proses Bisnis

George menyoroti bahwa "hasil utama dari penelitian kami adalah memeriksa bagaimana potensi ekosistem API e-faktur dapat dipercepat dengan menggunakan pemodelan proses bisnis (BPM)."

BPM adalah teknologi dan prinsip-prinsip yang membantu bisnis memahami prosesnya. Dengan cara ini, beberapa API yang menyediakan berbagai layanan mikro yang dibutuhkan dapat dihubungkan satu sama lain untuk mendorong inovasi. 

Sebagai contoh (gambar 3), ketika sebuah restoran kecil mengambil data pesanan makan malam dari API Uber Eats, informasi tersebut dikirim ke CRM API Salesforce untuk mengelola prioritas pesanan makan malam dan catatan keuangan. Ketika persediaan habis ke tingkat tertentu, BPM akan memicu API rantai pasokan supermarket Woolworths untuk meminta bahan tambahan. Setelah pesanan selesai, statusnya dikirim kembali ke API Uber Eats.

BPM juga menyediakan tata letak visual dari fungsionalitas utama, dan bisnis dapat menggunakan informasi ini untuk memahami fungsionalitas apa yang memerlukan integrasi API. Manfaat tambahan dari BPM adalah potensi untuk otomatisasi. Setelah proses pengaturan BPM selesai, API dapat mengotomatiskan pemeriksaan, pengiriman, dan penerimaan faktur elektronik.

Studi yang dilakukan oleh Fethi dan George memberikan kesempatan untuk mempelajari lebih dalam tentang ekosistem API faktur elektronik. Bagi warga Australia, penelitian ini merupakan penelitian yang tepat waktu karena menggunakan ekosistem API untuk memenuhi persyaratan yang kompleks seperti adopsi jaringan PEPPOL. Bagi komunitas pengembang, artikel ini menimbulkan pertanyaan apakah ekosistem API dapat diterapkan di industri lain.

Sama seperti tujuan utama Lego adalah untuk "menginspirasi dan mengembangkan para pembangun di masa depan", ekosistem API hadir untuk membangun masa depan di esok hari.

🔬🧫🧪🔍🤓👩‍🔬🦠🔭📚