Apa itu onboarding EDI?

EDI mengacu pada sistem dan standar untuk mengirimkan data dan dokumen bisnis secara elektronik (dan sering kali secara otomatis) dan real-time, termasuk faktur, pesanan pembelian, dan informasi rantai pasokan, antara mitra dagang.

Dalam transaksi EDI, informasi bergerak secara langsung dari aplikasi EDI di satu organisasi ke aplikasi EDI di organisasi lain. Standar EDI menentukan lokasi dan urutan informasi di setiap dokumen. 

Solusi EDI menawarkan banyak manfaat melalui otomatisasi, skalabilitas, dan standardisasi, dan EDI telah menjadi sarana pertukaran dokumen yang disukai untuk interaksi bisnis-ke-bisnis (B2B) selama beberapa dekade. Khususnya, formulir standar yang dibuat secara otomatis merampingkan dan mengurangi atau menghilangkan kebutuhan untuk memasukkan data secara manual, sehingga mengurangi kesalahan dan biaya terkait.  

Untuk beberapa bisnis, dan di beberapa industri, menggunakan EDI bukanlah pilihan, tetapi suatu kebutuhan. Banyak pengecer dan produsen besar memiliki persyaratan EDI dan kepatuhan untuk proses bisnis.

Variabilitas persyaratan dapat terjadi antara mitra dagang, seperti perbedaan dalam peraturan kepatuhan, persyaratan pemetaan dokumen, protokol komunikasi, atau proses pengujian. Hal ini dikombinasikan dengan kompleksitas umum standar EDI dapat membuat onboarding EDI menjadi proses yang sulit dan memakan waktu. 

Namun, proses orientasi internal yang terstandardisasi dan terdokumentasi dengan baik, perkakas middleware yang tepat, dan komunikasi yang jelas dengan mitra bisnis dapat mengurangi tantangan penyiapan EDI. Mereka juga membantu organisasi menuai manfaat EDI, termasuk akurasi data yang lebih besar dan kemampuan untuk bertransaksi dengan bisnis yang memerlukan kepatuhan EDI.

Dengan mengintegrasikan platform EDI dengan sistem perusahaan internal lainnya, seperti platform perencanaan sumber daya perusahaan (ERP), perusahaan dapat membangun pipeline otomatis. Pipeline ini dapat mengirimkan data bisnis standar ke mitra dan menyinkronkan sistem internal dengan platform EDI.

Integrasi ini “melengkapi pipeline,” memungkinkan aliran data otomatis, tidak hanya antara mitra pada perangkat lunak EDI, tetapi dari mitra bisnis ke aplikasi back-end organisasi dan sistem bisnis. Setelah terintegrasi, aplikasi EDI dapat mengekstrak data dari platform internal (seperti sistem ERP), mengubah informasi ini menjadi format EDI standar, dan mengirimkan file dengan aman ke mitra dagang. Integrasi otomatis ini makin mengurangi entri data manual dengan menghilangkan kebutuhan untuk rekey data dari platform internal ke platform EDI.

Onboarding EDI dapat merujuk pada pengaturan platform EDI saja, atau konfigurasi platform dan integrasinya dengan sistem perusahaan internal. Mengingat pentingnya sistem terintegrasi dalam lingkungan TI modern, biasanya yang dimaksud adalah yang kedua.

Onboarding akan terlihat berbeda di setiap kasus, tetapi langkah-langkah berikut adalah komponen penting dari sebagian besar proses onboarding.

Pada langkah pertama onboarding, calon mitra dagang baru harus memberikan dan mendiskusikan dasar-dasar teknologi tentang bagaimana koneksi EDI dapat bekerja. Perjanjian ini biasanya dinyatakan melalui perjanjian mitra dagang, atau TPA. TPA adalah kontrak yang menjabarkan ruang lingkup penuh pertukaran EDI yang dimaksud antara mitra dagang EDI. TPA mencakup jenis dokumen dan standar, tetapi juga persyaratan kewajiban, aturan kepatuhan, panjang kontrak, protokol komunikasi, dan banyak lagi. Negosiasi pra-penyiapan untuk orientasi mitra semacam ini akan menentukan tahapan untuk siklus orientasi selanjutnya.

Beberapa poin penting yang perlu dipertimbangkan meliputi:

Sifat dokumen yang terlibat menentukan banyak langkah selanjutnya dalam proses onboarding EDI; beberapa industri atau lokasi bisnis mungkin memerlukan standar yang berbeda atau langkah-langkah keamanan yang berbeda. Dokumen yang paling umum dipertukarkan melalui EDI termasuk Pesanan Pembelian 850, Faktur 810, dan Pengakuan Fungsional 997.

Standardisasi adalah komponen utama EDI, tetapi ada beberapa standar untuk tujuan yang berbeda. Standar umum termasuk ANSI ASC X12 (kadang-kadang disebut X12), yang paling umum di Amerika Utara. HIPAA mengamanatkan versi spesifik dari standar tersebut untuk transaksi perawatan kesehatan dan informasi medis. EDIFACT adalah standar internasional umum yang dikembangkan oleh PBB.

Langkah kedua dari onboarding EDI melibatkan pertukaran spesifikasi teknologi; pada dasarnya, ini adalah diskusi dan kesepakatan tentang cara yang tepat di mana dokumen akan dipertukarkan. 

Ada beberapa protokol komunikasi yang berbeda yang dapat digunakan untuk mengirimkan dokumen sesuai dengan prinsip EDI. Yaitu antara lain:

• AS2 (Applicability Statement 2): Protokol umum yang mendukung kepatuhan HIPAA serta fitur seperti tanda tangan digital dan pemberitahuan pengiriman.
  
  
• SFTP (Secure File Transfer Protocol): Protokol yang lebih lama, minimal dan mudah digunakan tetapi tidak memiliki beberapa fitur canggih yang ditemukan di AS2.
  
  
• MFT (Managed File Transfer): Sebuah evolusi FTP (File Transfer Protocol) dengan fitur yang lebih modern termasuk enkripsi menyeluruh dan jejak audit.
  
  
• SOAP (Simple Object Access Protocol): Sistem perpesanan berbasis XML agnostik platform, kadang-kadang ditemukan dalam sistem EDI lama.

Panduan implementasi EDI adalah dokumen yang mendefinisikan banyak aspek teknis dari pertukaran data. Panduan implementasi sering mencakup semua yang telah kita bahas sejauh ini, termasuk protokol, jenis dokumen, dan standar.

Tetapi panduan implementasi juga menggali lebih dalam dokumen itu sendiri, menentukan bidang mana yang harus diisi di setiap jenis dokumen, kode ID untuk setiap pertukaran untuk mengidentifikasi pengirim dan penerima, dan aturan khusus mitra lainnya. Panduan implementasi banyak digunakan dan berguna untuk organisasi besar dengan volume transaksi tinggi, karena kebingungan atau kesalahan apa pun dapat menyebabkan gangguan yang signifikan.

Sekarang semua spesifikasi dan kontrak telah disiapkan, langkah selanjutnya melibatkan pengaturan infrastruktur untuk pertukaran EDI.

Membangun antarmuka EDI dari awal dimungkinkan, tetapi lebih umum bagi organisasi untuk menggunakan platform bawaan. Platform penyedia EDI modern sering menyertakan integrasi untuk platform perusahaan internal lainnya, seperti platform ERP (perencanaan sumber daya perusahaan) dan WMS (sistem manajemen gudang) untuk mengurangi kebutuhan entri data manual antar sistem. Untuk bisnis kecil, portal web berbasis cloud menawarkan biaya awal yang rendah dan fitur dasar untuk penggunaan EDI yang efisien, seperti integrasi ERP. Banyak dari solusi ini makin meningkatkan penggabungan alat AI untuk validasi dan pemeriksaan kepatuhan yang lebih canggih.

Organisasi yang lebih besar mungkin membutuhkan lebih banyak layanan pelanggan dan perhatian; layanan EDI terkelola menawarkan pemetaan, pengujian, dukungan, dan banyak lagi, meskipun dengan harga yang lebih tinggi daripada portal EDI web, tetapi dengan efisiensi operasional yang optimal.

Pemetaan bisa menjadi langkah yang membawa gesekan paling banyak. Pada dasarnya, pemetaan data adalah proses menerjemahkan data internal, yang mungkin dalam format XML, CSV, atau format lainnya, ke salah satu format EDI standar, seperti X12.

Sebagian besar platform EDI mencakup fungsionalitas pemetaan, sering kali dengan antarmuka drag-and-drop untuk menangani terjemahan aliran data. Ada juga perangkat lunak pemetaan EDI mandiri yang dapat memberikan kontrol yang lebih granular atas proses. Proses ini bisa menjadi sangat terperinci dan mendetail; setiap bidang data EDI individu perlu dipetakan sesuai dengan panduan implementasi.

Misalnya, pemasok mungkin menggunakan nomor komponen internal, tetapi menjual komponen itu ke peretail yang menggunakan SKU. Dalam hal ini, perlu ada tabel referensi silang yang mencatat bahwa nomor komponen adalah item yang sama dengan SKU. Masalah lain dengan pemetaan mungkin termasuk bidang yang digunakan oleh pemasok tetapi tidak oleh pelanggan, seperti “departemen” atau “lorong gudang.” Informasi seperti ini dapat menyebabkan kegagalan validasi, karena tidak cocok dan mungkin perlu diberi label sebagai kondisional atau opsional.

Banyak organisasi, seperti peritel besar, menawarkan pustaka templat pemetaan yang telah dibangun sebelumnya untuk mencoba membuat proses ini sedikit lebih mudah. Organisasi lain mungkin memilih untuk menyewa kontraktor pihak ketiga untuk menyiapkan peta.

EDI terkenal rewel, dengan tingkat kesalahan ketidakpatuhan yang tinggi, menurut analisis dari Long View Systems. Ketika kesalahan terjadi saat menerapkan EDI, mungkin ada efek bertingkat di rantai pasokan dan perdagangan. Inilah sebabnya mengapa pengujian adalah langkah penting dalam proses onboarding yang sukses.

Langkah pengujian konektivitas bertujuan untuk memastikan bahwa satu sistem dapat berkomunikasi dengan yang lain. Biasanya, ini dilakukan dengan pesan “TEST” sederhana, yang harus merespons dengan MDN, atau Pemberitahuan Disposisi Pesan (respons penerimaan otomatis). 

Langkah ini memeriksa apakah file EDI terstruktur dengan benar, sesuai dengan standar format EDI dan panduan implementasi. Ada beberapa elemen yang termasuk dalam validasi EDI. 

Yang paling mendasar mungkin validasi sintaks. Apakah semua kolom yang diperlukan sudah diisi? Apakah kolom-kolom tersebut sudah tersusun dengan benar? Apakah mereka diisi sesuai dengan tipe datanya (jadi, misalnya, tanggal ditulis sebagai YYYYMMDD bukan “18 Maret 2026")? 

Kategori validasi lainnya adalah validasi set kode. Apakah kode, seperti kode negara atau kode mata uang, cocok dengan daftar resmi yang diterima? 

Mengirim dokumen dummy adalah langkah penting untuk memastikan bahwa dokumen dikirim dan diterima dengan tepat. Tim di kedua sisi transaksi dapat menganalisis pesan kesalahan yang menyertainya dan melihat apa yang salah. Masalah umum termasuk nilai kode yang salah, kesalahan pemformatan, dan bidang wajib yang tidak lengkap. 

Setelah satu transaksi bekerja dengan baik, saatnya untuk pengujian secara menyeluruh terhadap proses. Langkah ini melibatkan memastikan bahwa integrasi dengan ERP atau platform lain bekerja tanpa kesalahan, bahwa setiap transaksi yang dikirim merespons 997 (formulir pengakuan fungsional), dan bahwa setiap langkah mengikuti dari sebelumnya. Alur kerja ini dapat berupa multi-tahap: apakah keberadaan pesanan pembelian memicu pengiriman pesanan faktur? 

Setelah pengujian selesai dan setiap mitra dagang mengakui bahwa sistem siap diluncurkan, platform diatur untuk ditayangkan. Ini mungkin berarti menyesuaikan platform EDI sehingga beralih dari lingkungan pengujian ke lingkungan produksi, yang dapat dilakukan secara bertahap atau sekaligus. 

Selama periode awal peluncuran EDI langsung, umumnya perhatian khusus diberikan pada setiap transaksi untuk memastikan bahwa semua beroperasi sebagaimana mestinya. Verifikasi manual umum dilakukan untuk transaksi awal ini, memeriksa untuk memastikan bahwa tidak ada yang tidak terduga dan tidak ada kesalahan yang muncul. 

Selama siklus hidup penuh EDI, salah satu mitra mungkin memutuskan untuk mengubah panduan implementasi. Misalnya, item baru dapat ditambahkan, jenis produk baru atau bidang baru. Ini pada gilirannya harus divalidasi dan diuji. EDI berjalan otomatis tetapi tidak diperbaiki—pembaruan dapat diimplementasikan saat diperlukan. 

Proses onboarding EDI sangat kompleks dan penuh dengan peluang untuk menimbulkan kesalahan dan frustrasi. Kesalahan umum termasuk