Apa itu EDI? Bagaimana EDI memudahkan pemesanan antarperusahaan ── dari FAX, email, dan input manual ke integrasi data

“Surat pesanan datang lewat FAX dari mitra dagang, lalu staf memasukkannya ke sistem manajemen penjualan.” “Excel yang dilampirkan di email dibuka, kode produk dan kuantitas dicek, lalu disalin.” “Setelah pengiriman, invoice dibuat, dan di pihak penerima isinya dimasukkan lagi ke sistem akuntansi.” ── Dalam transaksi antarperusahaan, informasi pesanan atau penagihan yang sama kadang dimasukkan berkali-kali oleh beberapa perusahaan dan beberapa staf.

Mekanisme yang mengurangi input berulang itu, dan menukar data pemesanan, penerimaan pesanan, pengiriman, penagihan, dan sebagainya secara langsung antar perusahaan, adalah EDI. Mendengar EDI, mungkin terbayang sistem besar yang diadopsi perusahaan besar lewat jalur khusus. Esensinya jauh lebih sederhana. Bukan orang yang membaca ulang informasi dari mitra dagang lalu memasukkannya, melainkan menukarnya sebagai data yang bisa diproses komputer secara langsung. Hanya itu.

Artikel ini menata apa itu EDI, apa bedanya dengan FAX dan email, dan bagaimana pekerjaan perusahaan menjadi lebih ringan jika diterapkan, dengan contoh pekerjaan pemesanan. Istilah teknis kami batasi seminimal mungkin, tetapi empat hal berikut perlu dipahami lebih dulu.

1. Kesimpulan lebih dulu

EDI adalah mekanisme agar perusahaan menukar informasi transaksi seperti surat pesanan, notifikasi pengiriman, dan invoice sebagai data elektronik dalam format yang sudah disepakati.

Japan Information Economy and Society Promotion Association (JIPDEC) adalah lembaga yang melakukan standardisasi dan penyebarluasan di bidang perdagangan elektronik, keamanan informasi, perlindungan data pribadi, dan sebagainya, serta terus menerbitkan informasi tentang kode perusahaan dan EDI. Artikel ini juga merujuk penjelasan asosiasi itu tentang definisi dan efek EDI. Penjelasan JIPDEC menjelaskan EDI sebagai “perusahaan, lembaga pemerintah, dan sebagainya menghubungkan komputer lewat jaringan, lalu menukar slip dan dokumen secara otomatis sebagai data elektronik”, dan sekaligus memperkenalkan definisi menurut JIS X 7011.

Tujuan menerapkan EDI bukan sekadar menghilangkan kertas. Tujuan utamanya adalah mengurangi pekerjaan seperti berikut.

• Input manual sambil melihat FAX atau PDF
• Penyalinan dari Excel ke sistem manajemen penjualan
• Pemeriksaan visual isi yang dimasukkan
• Pekerjaan mencari surat pesanan atau invoice
• Telepon atau email untuk mengonfirmasi status pesanan
• Penghitungan ulang data penjualan, stok, dan penagihan

Dalam satu kalimat, EDI adalah mekanisme yang membuat data yang tadinya berhenti di antara perusahaan mengalir apa adanya.

Peta pengetahuan artikel ini

EDI adalah mekanisme agar perusahaan menukar informasi transaksi seperti surat pesanan, notifikasi pengiriman, dan invoice dalam format data elektronik yang sudah disepakati, sehingga input ulang manual itu sendiri hilang. Selain mengurangi kesalahan penyalinan dan mempercepat pemrosesan pesanan, efeknya baru muncul jika data yang diterima dihubungkan sampai sistem stok, pengiriman, dan penagihan internal; jika dicetak lalu diproses orang, keadaannya tidak berbeda dari FAX. Format yang disesuaikan per mitra dagang menaikkan biaya, sehingga EDI berbasis standar atau EDI bersama untuk UKM menjadi pilihan yang realistis. Invoice digital adalah penerapan pendekatan ini ke bidang penagihan, dan sebelum penerapan, menginventarisasi metode pemesanan dan penerimaan pesanan saat ini per mitra dagang lebih diutamakan daripada pemilihan produk.

flowchart LR
    accTitle: Peta pengetahuan pertukaran data antar perusahaan lewat EDI
    accDescr: Diagram yang menunjukkan bagaimana EDI mencegah input ulang manual dan kesalahan penyalinan, mengotomatiskan pemrosesan pesanan serta integrasi stok, pengiriman, dan penagihan; bagaimana EDI berbasis standar dan EDI bersama untuk UKM menjawab masalah format individual; dan bagaimana invoice digital menerapkan pendekatan ini ke bidang penagihan.
    edi["EDI (pertukaran data elektronik)"]
    manual_reentry["input ulang manual atas informasi yang diterima"]
    transcription_error["kesalahan input karena penyalinan"]
    order_processing_lead_time["lead time pemrosesan pesanan"]
    trading_partner_agreement["kesepakatan EDI dengan mitra dagang"]
    master_code_alignment["keselarasan master seperti kode produk"]
    order_to_cash_integration["integrasi stok, pengiriman, dan penagihan setelah pesanan"]
    edi_standard_format["EDI berbasis standar"]
    edi_individual_format["EDI individual per mitra dagang"]
    sme_common_edi["EDI bersama untuk UKM"]
    digital_invoice["invoice digital"]
    current_process_inventory["inventarisasi metode pemesanan saat ini"]
    order_status_visibility["visibilitas status pesanan"]
    task_personalization["ketergantungan pekerjaan pada individu"]
    low_frequency_irregular_trading["transaksi jarang dan tidak terpola"]
    high_frequency_recurring_trading["transaksi berulang yang sering dan terpola"]
    edi -->|"mengurangi"| manual_reentry
    manual_reentry -->|"dapat menyebabkan"| transcription_error
    edi -.->|"mengurangi"| transcription_error
    edi -->|"mengurangi"| order_processing_lead_time
    edi -->|"mensyaratkan"| trading_partner_agreement
    edi -->|"mensyaratkan"| master_code_alignment
    edi -->|"mengotomatiskan"| order_to_cash_integration
    edi -.->|"mensyaratkan"| order_to_cash_integration
    edi -->|"menggunakan"| edi_standard_format
    edi_standard_format -->|"disarankan untuk"| edi_individual_format
    sme_common_edi -->|"disarankan untuk"| edi_individual_format
    digital_invoice -.->|"menggunakan"| edi
    current_process_inventory -->|"sebaiknya didahului"| edi
    edi -->|"mengotomatiskan"| order_status_visibility
    order_status_visibility -->|"mengurangi"| task_personalization
    edi -.->|"tidak disarankan"| low_frequency_irregular_trading
    edi -->|"disarankan untuk"| high_frequency_recurring_trading

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 17, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Apa yang terjadi pada pemesanan tanpa EDI

Pertama, bayangkan pekerjaan pemesanan yang tidak memakai EDI. Di perusahaan sisi pemesan, staf pembelian membuat isi pesanan di sistem sendiri atau Excel, mencetaknya sebagai surat pesanan, lalu mengirimkannya ke mitra dagang lewat FAX atau email. Di sisi penerima, staf memeriksa surat pesanan yang datang, lalu memasukkannya ke sistem manajemen penjualan sendiri. Setelah itu dibuat konfirmasi pesanan, notifikasi pengiriman, surat jalan, invoice, dan sebagainya, dikirim kembali ke sisi pemesan, dan di sisi pemesan informasi itu dimasukkan lagi ke sistem manajemen stok atau sistem akuntansi.

flowchart TD
    accTitle: Alur pemesanan tanpa EDI
    accDescr: Diagram yang menunjukkan data pesanan dicetak atau diubah ke PDF, dikirim lewat FAX atau email, diinput ulang di sisi penerima, lalu sisi pemesan memasukkan lagi data pengiriman dan penagihan ke sistemnya sendiri.
    A["Sisi pemesan memasukkan data pesanan"] --> B["Surat pesanan dicetak atau diubah ke PDF"]
    B --> C["Dikirim lewat FAX atau email"]
    C --> D["Staf sisi penerima memeriksa isinya"]
    D --> E["Dimasukkan ulang ke sistem sisi penerima"]
    E --> F["Data pengiriman dan data penagihan dibuat"]
    F --> G["Sisi pemesan memasukkan lagi ke sistemnya sendiri"]

Gambar 1: Alur pemesanan tanpa EDI. Data dimasukkan ulang lewat tangan orang sebanyak dua kali.

Dalam alur ini, informasi yang sama seperti kode produk, nama produk, kuantitas, harga satuan, tanggal kirim, dan tujuan kirim dimasukkan berkali-kali. Data pesanan awal sudah ada di komputer sisi pemesan, tetapi karena diubah menjadi kertas atau PDF, di sisi penerima orang harus membacanya lagi dan memasukkannya ulang ke komputer.

Masalahnya bukan bahwa informasi belum didigitalkan. Masalahnya adalah informasi yang sekali sudah dibuat sebagai data diubah menjadi dokumen untuk dibaca orang, lalu di pihak lain diubah kembali menjadi data.

3. Bagaimana pemesanan berubah jika memakai EDI

Dengan EDI, data pesanan yang dibuat di sistem sisi pemesan diubah ke format yang dapat dibaca sistem sisi penerima, lalu dikirim begitu saja. Di sisi penerima, staf tidak memasukkan sambil melihat surat pesanan; data yang diterima diimpor ke sistem manajemen penjualan.

flowchart LR
    accTitle: Alur pemesanan dengan EDI
    accDescr: Diagram yang menunjukkan data pesanan berpindah dari sistem pembelian sisi pemesan lewat EDI ke sistem manajemen penjualan sisi penerima, lalu konfirmasi pesanan, notifikasi pengiriman, dan data penagihan kembali lewat jalur yang sama.
    A[Sistem pembelian sisi pemesan] --> B[Data pesanan]
    B --> C[Pengiriman dan konversi lewat EDI]
    C --> D[Sistem manajemen penjualan sisi penerima]
    D --> E[Konfirmasi pesanan]
    D --> F[Notifikasi pengiriman]
    D --> G[Data penagihan]
    E --> C
    F --> C
    G --> C
    C --> A

Gambar 2: Alur pemesanan dengan EDI. Langkah “cetak”, “pemeriksaan visual”, dan “input ulang” yang ada di Gambar 1 sudah hilang.

Data pesanan dikirim dari sisi pemesan ke sisi penerima, dan data konfirmasi pesanan, pengiriman, penagihan, dan sebagainya dikembalikan dari sisi penerima ke sisi pemesan. Intinya adalah data diserahkan dari sistem ke sistem, tanpa langkah orang menyalin sambil melihat dokumen.

Dalam penjelasan JIPDEC, EDI dijelaskan sebagai mekanisme yang mengubah data berformat khas tiap perusahaan ke format standar, dan di sisi penerima mengubah lagi dari format standar ke format sendiri.

4. Apa bedanya EDI dengan email, PDF, dan Excel

Kadang ada anggapan “surat pesanan sudah dijadikan PDF dan dikirim email, jadi sudah didigitalkan”. Memang lebih cepat daripada mengirim kertas lewat pos, dan lebih mudah disimpan. Namun jika pihak penerima masih memasukkan ke sistem sambil melihat PDF, pekerjaan input itu sendiri masih ada. Perbedaannya dapat ditata sebagai berikut.

Dalam penjelasan JIPDEC, gambar hasil pindai slip, atau email yang ditulis sebagai teks biasa, dibedakan dari data EDI yang dapat diproses ulang oleh komputer. Selain itu, cara orang menginput manual ke layar Web, secara ketat, juga berbeda dari pertukaran otomatis antarkomputer.

Namun memakai PDF atau Excel itu sendiri bukan hal buruk. Yang penting adalah bagaimana informasi yang diterima diproses setelahnya. “Orang melihat PDF lalu memasukkan”, “Excel dibuka lalu disalin”, “CSV diimpor langsung ke sistem”, “didaftarkan otomatis lewat API” ── meski sama-sama “berkas elektronik”, beban proses berikutnya sangat berbeda. Saat menilai efek EDI, yang perlu dilihat bukan hanya cara mengirim, melainkan apa yang dilakukan orang setelah data diterima.

4.1. Peta hal-hal yang disebut “EDI”

Sejauh ini “EDI” ditulis sebagai satu istilah, tetapi begitu mulai ditinjau di lapangan, muncul banyak sebutan. Jika posisi keseluruhannya dipahami lebih dulu, penjelasan produk tidak membuat bingung.

Sumbu klasifikasinya hanya dua. Pertama, apakah format pertukaran adalah spesifikasi individual per mitra, atau standar yang disepakati luas. Kedua, apakah pada akhirnya orang mengoperasikan layar, atau data berpindah dari sistem ke sistem. Jika kondisi sendiri dan kandidat diletakkan pada dua sumbu ini, terlihat di mana perbaikan akan memberi efek.

5. Informasi yang dapat ditukar dengan EDI

EDI bukan mekanisme untuk surat pesanan saja. Berbagai informasi yang muncul dalam transaksi antarperusahaan dapat ditukar.

Misalnya, pada saat data pemesanan diterima, sistem sisi penerima juga dapat melakukan pemrosesan berikut.

1. Memeriksa duplikasi nomor pesanan
2. Memeriksa apakah kode produk ada
3. Mengalokasikan stok
4. Menghitung tanggal kirim
5. Mengirim instruksi pengiriman ke gudang
6. Mengembalikan konfirmasi pesanan ke sisi pemesan

Setelah pengiriman, penjualan dapat dicatat dari realisasi pengiriman, dan data penagihan dapat dibuat. Artinya EDI bukan sekadar fungsi komunikasi, melainkan fondasi untuk menghubungkan, dengan pemesanan sebagai pintu masuk, stok, pengiriman, penjualan, dan penagihan setelahnya.

6. Bagaimana EDI meringankan pekerjaan perusahaan

Seperti terlihat di bab 2 sampai bab 4, efek langsung EDI adalah “input manual sambil melihat surat pesanan hilang”. Bab ini menata, dalam enam bagian, apa yang terjadi setelah itu. Efeknya bukan hanya pengurangan tenaga input.

6.1. Waktu staf dapat dialihkan ke penanganan pengecualian

Jika input manual hilang, cara staf memakai waktu berubah. Bukan semua pesanan diproses orang, melainkan pesanan biasa diproses otomatis, dan hanya yang memerlukan pertimbangan yang dicek orang. Pesanan yang perlu dilihat orang, misalnya, adalah sebagai berikut.

• Pesanan yang stoknya kurang
• Pesanan dengan tanggal kirim yang berbeda dari biasanya
• Pesanan dengan kode produk yang belum terdaftar
• Pesanan volume besar
• Pesanan yang memerlukan konfirmasi harga satuan atau syarat kontrak

Dalam keadaan terburu-buru karena input, pemeriksaan ini cenderung ditunda. Nilai EDI lebih pada “waktu yang berkurang dapat dipakai untuk pesanan yang memang perlu perhatian”, daripada pada “pekerjaan berkurang”.

6.2. Kesalahan input dapat dikurangi

Pada pekerjaan yang dimasukkan orang, kesalahan terjadi dengan probabilitas tertentu. Keliru satu digit pada kode produk, memasukkan kuantitas 100 alih-alih 10, tertukar tujuan kirim, salah membaca tanggal kirim yang diinginkan, mendaftarkan pesanan yang sama dua kali, dan sejenisnya.

Pada EDI pun, jika data aslinya salah, masalah tetap terjadi. Namun karena data yang dibuat dengan benar tidak perlu dimasukkan ulang di pihak lain, kesalahan yang muncul pada tahap penyalinan dapat dikurangi. Badan UKM Jepang juga menyebut, sebagai efek digitalisasi pemesanan, peningkatan efisiensi kerja, pengurangan kesalahan manusia, dan peningkatan kemampuan pencarian catatan transaksi.

6.3. Pemrosesan pesanan dapat dipercepat

Pada FAX atau email, pemrosesan pesanan tidak mulai sampai staf menyadari penerimaan, memeriksa isi, dan selesai memasukkan. Pada hari pesanan banyak, antrean input terjadi, dan jika staf absen, pemrosesan tertunda.

Pada EDI, data yang diterima dapat diimpor otomatis ke sistem, sehingga segera setelah pesanan diterima, pemrosesan seperti penerimaan pesanan, pemeriksaan stok, perhitungan tanggal kirim, instruksi pengiriman ke gudang, dan pengembalian konfirmasi pesanan dapat dimulai. Jika pemrosesan pesanan lebih cepat, waktu sampai pengiriman juga lebih mudah dipendekkan. JIPDEC juga menyebut, sebagai efek EDI, efisiensi dan percepatan pekerjaan administrasi, pengiriman just-in-time, pemendekan lead time, dan penekanan stok.

6.4. Status pesanan menjadi lebih mudah dicek

Jika kertas, FAX, email, dan Excel bercampur, menelusuri “bagaimana keadaan pesanan itu sekarang” memakan waktu. Kotak email staf, folder bersama, arsip kertas, sistem manajemen penjualan, dan sebagainya harus dicek berurutan.

Pada EDI, dengan nomor pesanan dan sejenisnya sebagai acuan, informasi berikut dapat dikaitkan dan dikelola.

• Kapan pesanan diterima
• Apakah diimpor dengan benar
• Apakah konfirmasi pesanan sudah dikembalikan
• Apakah sudah dikirim
• Apakah sudah diinspeksi penerimaannya
• Apakah sudah ditagih
• Apakah terjadi error atau pengiriman ulang

Saat ada pertanyaan pun, konfirmasi dapat dilakukan dari riwayat pemrosesan, tanpa mengandalkan ingatan staf atau email pribadi.

6.5. Dapat dihubungkan ke stok, pengiriman, dan akuntansi

Jika data yang diterima dihubungkan ke sistem internal, proses setelah pendaftaran pesanan juga dapat diotomatisasi.

flowchart TD
    accTitle: Proses lanjutan internal setelah data pesanan diterima
    accDescr: Diagram yang menunjukkan proses lanjutan mulai dari penerimaan data pesanan, pendaftaran pesanan, alokasi stok, instruksi pengiriman, pencatatan penjualan, pembuatan data penagihan, hingga rekonsiliasi pembayaran.
    A["Data pesanan diterima"] --> B["Pendaftaran pesanan"]
    B --> C["Alokasi stok"]
    C --> D["Instruksi pengiriman"]
    D --> E["Pencatatan penjualan"]
    E --> F["Pembuatan data penagihan"]
    F --> G["Rekonsiliasi pembayaran"]

Gambar 3: Proses lanjutan yang dilalui data pesanan yang diterima di internal. Seberapa jauh dihubungkan menentukan efek penerapan.

Sebaliknya, meski data pesanan diterima lewat EDI, jika dicetak lalu orang memasukkannya ke sistem manajemen penjualan, efeknya terbatas. JIPDEC juga menjelaskan bahwa jika data yang diterima lewat EDI tidak diimpor ke sistem internal, melainkan dicetak dan diproses orang, keadaannya tidak jauh berbeda dari FAX. EDI bukan hanya menerapkan komunikasi dengan mitra dagang; yang penting adalah seberapa jauh data yang diterima dialirkan ke pekerjaan internal.

6.6. Data transaksi dapat dipakai untuk keputusan manajemen

Surat pesanan yang diterima sebagai kertas atau PDF, meski disimpan, sulit dipakai untuk agregasi. Pada EDI, informasi transaksi terkumpul sebagai data terstruktur, sehingga dapat dihubungkan ke analisis seperti berikut.

• Volume pesanan per produk
• Perkembangan penjualan per mitra dagang
• Kecenderungan pesanan per hari dalam seminggu atau per rentang waktu
• Kejadian keterlambatan pengiriman
• Produk yang sering kehabisan stok
• Waktu yang dibutuhkan dari pesanan sampai pengiriman
• Transaksi dengan banyak retur atau koreksi

JIPDEC juga menyatakan bahwa data EDI dapat dipakai, selain untuk pekerjaan harian seperti alokasi stok, pengaturan produksi, inspeksi masuk-keluar, dan pencatatan piutang, juga sebagai bahan keputusan manajemen seperti analisis produk laris, spend analysis, dan peramalan permintaan. Menciptakan keadaan di mana data dapat dikumpulkan lewat EDI bukan hanya efisiensi operasional, melainkan juga prasyarat bagi optimalisasi stok dan peramalan permintaan di masa depan.

7. Efek EDI dalam contoh sederhana

Misalnya, suatu perusahaan grosir menerima 100 pesanan per hari lewat FAX atau email, dan memasukkan serta memeriksa satu pesanan ke sistem manajemen penjualan rata-rata memakan 3 menit.

100 pesanan × 3 menit = 300 menit → 5 jam per hari

Setelah EDI diterapkan, 80 pesanan diimpor otomatis, dan hanya 20 sisanya yang dicek orang, maka menjadi seperti ini.

20 pesanan × 3 menit = 60 menit → 1 jam per hari

Ini contoh yang disederhanakan, tetapi pekerjaan input berubah dari 5 jam menjadi 1 jam. Di lapangan, di samping itu, waktu untuk memeriksa FAX yang sulit dibaca, mengoreksi kesalahan input, menelepon untuk mengonfirmasi isi pesanan, mencari surat pesanan, mengagregasi daftar pesanan, dan serah terima antar staf juga berpotensi berkurang. Efek penerapan EDI bukan hanya biaya langsung seperti “biaya kertas berkurang”; artinya yang besar adalah mengurangi konfirmasi, input, dan koreksi kecil yang berulang setiap hari.

7.1. Hitung dengan angka sendiri

100 pesanan dan 3 menit di atas hanyalah contoh. Cobalah terapkan angka sendiri dan hitung. Yang diperlukan hanya empat angka.

(1) Jumlah pesanan per hari                       …… A pesanan
(2) Waktu input dan pemeriksaan per pesanan       …… B menit
(3) Perkiraan persentase yang dapat diproses
    otomatis dengan EDI                           …… C %
(4) Jumlah hari kerja dalam setahun               …… D hari

Waktu yang dipakai sekarang   = A × B                    (menit/hari)
Waktu yang tersisa setelah EDI = A × (1 - C ÷ 100) × B    (menit/hari)
Pengurangan waktu per hari    = A × (C ÷ 100) × B        (menit/hari)
Pengurangan waktu per tahun   = pengurangan waktu per hari × D ÷ 60  (jam/tahun)

“(3) persentase yang dapat diproses otomatis” ditentukan oleh banyaknya pengecualian yang dibahas di bab berikutnya. Jangan menaruh nilai tinggi dari awal; mulailah dari menghitung berapa persen dari keseluruhan yang diwakili beberapa mitra teratas menurut jumlah transaksi. Jumlah per mitra dagang muncul jika tabel di bab 11.1 dibuat.

Perlu dicatat, yang keluar dari perhitungan ini adalah waktu yang dapat dikurangi, bukan biaya tenaga kerja yang langsung terpotong. Baru setelah diputuskan untuk apa waktu yang longgar dipakai (menaikkan mutu penanganan pengecualian, dialihkan ke pekerjaan lain, mengurangi lembur), angka itu dapat dijelaskan sebagai efek penerapan.

8. Manfaat EDI per bagian

Peningkatan operasional lewat EDI tidak terbatas pada bagian penerimaan pesanan.

Lokasi informasi menjadi jelas, dan status lebih mudah dicek bahkan oleh orang selain staf yang bersangkutan. Karena itu, yang dapat dikurangi EDI bukan hanya tenaga input, melainkan juga ketergantungan pekerjaan pada individu tertentu.

9. Menerapkan EDI tidak berarti semuanya otomatis

EDI adalah mekanisme yang berguna, tetapi menerapkannya saja tidak membuat semua pekerjaan otomatis.

9.1. Perlu kesepakatan dengan mitra dagang

Untuk menukar data antar perusahaan, setidaknya hal berikut perlu diputuskan. Informasi apa yang ditukar, format data apa yang dipakai, kapan dikirim dan diterima, bagaimana menangani perubahan atau pembatalan pesanan, apa yang dilakukan jika terjadi error, bagaimana menangani jika data yang sama dikirim ulang, dan pada titik mana pesanan dianggap sah.

Kesepakatan itu berlapis, dan JIPDEC menatanya menjadi lima berikut. Jika “menerapkan EDI” disalahpahami sebagai lapisan yang mana, pembicaraan tidak nyambung.

Perbandingan produk dan layanan cenderung condong ke dua lapisan atas (protokol komunikasi dan aturan sintaksis), tetapi yang menyulitkan saat penerapan adalah tiga lapisan bawah. Khususnya “pesan dan kolom data” adalah penataan kode itu sendiri yang dibahas di 9.2; jika ini tidak dibahas tuntas bersama mitra dagang lalu produk saja yang diputuskan, pekerjaan akan diulang kemudian.

9.2. Kode produk dan sejenisnya perlu diselaraskan

Sisi pemesan dan sisi penerima kadang memakai kode berbeda untuk produk yang sama. Misalnya kode produk A-001 di sisi pemesan, dan 100245 di sisi penerima. Dalam kasus itu, tabel korespondensi untuk mengonversi kode diperlukan. Selain kode produk, butir berikut juga ditata.

• Kode mitra dagang
• Kode tujuan kirim
• Satuan
• Isi kemasan
• Klasifikasi pajak
• Mata uang
• Format tanggal
• Encoding karakter

Meski data dapat dikirim dan diterima, jika makna kolom tidak cocok, transaksi yang benar tidak terbentuk.

9.3. Penanganan pengecualian tetap ada

Meski pesanan biasa dapat diproses otomatis, transaksi pengecualian seperti stok kurang, produk dihentikan, harga yang berbeda dari biasanya, pesanan darurat, perubahan pesanan, pembatalan pesanan, pengiriman bertahap, retur, dan data tidak lengkap tetap ada.

Yang penting bukan memaksakan otomatisasi semuanya. Yang realistis adalah memisahkan pemrosesan biasa dan pemrosesan pengecualian, mengotomatisasi yang biasa, dan hanya yang memerlukan pertimbangan yang diteruskan ke orang. “Pesanan yang perlu dilihat orang” yang disebut di bab 6.1, itulah pengecualian yang dimaksud di sini.

9.4. Periode penggunaan bersama dengan FAX dan email akan terjadi

Tidak semua mitra dagang dapat pindah ke EDI sekaligus. Karena itu, pada awal penerapan, beberapa cara penerimaan seperti EDI, layar Web, unggah CSV, email, FAX, dan telepon kadang berjalan bersamaan.

Dalam keadaan ini, meski EDI diterapkan, personel untuk pekerjaan lama tidak dapat langsung dikurangi. Untuk menaikkan efek, mitra dagang dengan volume transaksi besar perlu dimigrasikan berurutan, sambil mengurangi jumlah yang ditangani manual. JIPDEC juga menunjukkan bahwa jika pemrosesan manual seperti FAX dan telepon tersisa, tenaga untuk menanganinya tetap diperlukan, sehingga efek efisiensi sulit diperoleh sepenuhnya. Alasan “persentase yang dapat diproses otomatis” pada perhitungan bab 7.1 sebaiknya diletakkan secara hati-hati juga ada di sini.

10. Perusahaan yang cocok untuk EDI

EDI adalah mekanisme yang efeknya mudah muncul terutama di perusahaan seperti berikut.

• Setiap hari atau setiap minggu memesan dengan mitra dagang yang sama
• Jumlah pesanan atau jumlah baris rincian banyak
• Menyalin dari FAX atau email ke sistem
• Terjadi kesalahan input atau registrasi ganda
• Telepon atau email konfirmasi pesanan banyak
• Setelah pesanan diterima, pemrosesan stok, pengiriman, dan penagihan berlanjut
• Jika staf absen, pemrosesan tersendat
• Agregasi riwayat pesanan atau status transaksi memakan waktu

Sebaliknya, untuk mitra yang hanya bertransaksi beberapa kali setahun, atau transaksi yang isi pesanannya sangat berbeda setiap kali, biaya membangun dan mengoperasikan EDI kadang melebihi efeknya.

Apakah menerapkan EDI tidak diputuskan hanya dari skala perusahaan. Badan UKM Jepang juga menyusun “EDI bersama untuk UKM” yang menstandarkan pekerjaan pemesanan bagi UKM, dan menunjukkan efisiensi operasional dengan mengurangi terminal khusus dan kertas, serta mengelola slip secara terpusat sebagai data. Yang perlu dilihat bukan jumlah karyawan, melainkan volume input, pemeriksaan, dan penyalinan yang berulang.

11. Cara maju saat meninjau penerapan EDI

Saat meninjau EDI, tidak perlu dari awal memilih produk atau cara komunikasi. Pertama, tata dulu pekerjaan saat ini.

11.1. Buat daftar metode pemesanan saat ini

Per mitra dagang, tata informasi berikut.

Dengan menata ini, mitra dagang atau pekerjaan yang efek digitalisasi EDI-nya besar menjadi terlihat. Jumlah dan waktu yang dimasukkan ke perhitungan bab 7.1 juga diambil dari tabel ini.

11.2. Mulai dari satu mitra dengan volume transaksi besar

Jika dari awal semua mitra dijadikan sasaran, butir yang harus diselaraskan bertambah, dan penerapan menjadi panjang. Yang realistis adalah memilih dulu satu mitra yang memenuhi syarat berikut.

• Jumlah transaksi banyak
• Banyak pesanan yang terpola
• Komunikasi antar staf lancar
• Ada pemahaman terhadap integrasi sistem
• Efeknya mudah diukur

Setelah cara operasional ditetapkan dengan satu mitra, perluas ke mitra lain.

11.3. Persempit sasaran yang ditukar

Tidak perlu dari awal mencakup semua: penawaran, penerimaan pesanan, pengiriman, inspeksi, penagihan, dan pembayaran. Misalnya, hanya data pesanan yang beban inputnya paling besar yang lebih dulu dijadikan EDI, lalu diperluas secara bertahap seperti berikut.

1. Tahap 1: data pesanan
2. Tahap 2: konfirmasi pesanan dan jawaban tanggal kirim
3. Tahap 3: notifikasi pengiriman
4. Tahap 4: data penagihan

Dengan menambah sasaran secara bertahap, efek dapat dikonfirmasi sambil menekan dampak ke lapangan.

11.4. Periksa koneksi ke sistem internal

Meski layanan EDI diterapkan, jika data tidak dapat diimpor ke sistem manajemen penjualan yang ada, input manual tetap tersisa. Periksa lebih dulu hal berikut.

• Apakah ada fungsi input-output CSV
• Apakah API dapat dipakai
• Apakah integrasi dengan basis data memungkinkan
• Di mana konversi kode produk dilakukan
• Bagaimana mencegah duplikasi data yang diterima
• Kepada siapa error diberitahukan
• Di mana riwayat pemrosesan disimpan

Lebih penting memeriksa cara koneksi ke sistem yang ada sebelum pemilihan produk. Jika di sini diketahui “input-output CSV tidak bisa” atau “tidak ada API”, yang didahulukan bukan pemilihan layanan EDI, melainkan perbaikan di sisi sistem yang ada atau menyiapkan mekanisme perantara.

12. Indikator yang ingin diukur setelah EDI diterapkan

Setelah EDI diterapkan, jangan berhenti di “sudah bisa dipakai”; periksa seberapa jauh pekerjaan berubah. Misalnya, bandingkan indikator berikut sebelum dan sesudah penerapan. Jika angka yang dipakai di perhitungan bab 7.1 diganti langsung dengan nilai terukur, selisih antara perkiraan dan kenyataan juga langsung terlihat.

• Waktu untuk input pesanan
• Waktu sampai satu pesanan selesai diproses
• Jumlah koreksi input
• Jumlah registrasi ganda
• Jumlah pertanyaan konfirmasi pesanan
• Jumlah keterlambatan pengiriman
• Proporsi pesanan yang diproses dengan EDI
• Proporsi pesanan pengecualian yang dicek orang

Yang penting pada EDI bukan dapat mengirim data. Evaluasinya adalah apakah pekerjaan manual benar-benar berkurang, pemrosesan menjadi lebih cepat, dan kesalahan berkurang.

Ringkasan

EDI adalah mekanisme menukar informasi pesanan, pengiriman, penagihan, dan sebagainya yang muncul antar perusahaan sebagai data elektronik yang dapat diproses komputer secara langsung. Hanya mengubah FAX menjadi email kadang mengurangi kertas, tetapi input manual tetap ada. Efek EDI yang sesungguhnya ada pada kemampuan menghubungkan data yang diterima dari mitra dagang secara langsung ke sistem internal seperti manajemen penjualan, stok, pengiriman, dan akuntansi.

Perubahan utama yang diharapkan dari EDI adalah sebagai berikut.

• Mengurangi input manual sambil melihat surat pesanan
• Mengurangi kesalahan input karena penyalinan
• Mempercepat pemrosesan dari penerimaan pesanan sampai pengiriman
• Membuat status pemrosesan pesanan dan penagihan lebih mudah dicek
• Menghubungkan stok, pengiriman, penjualan, dan penagihan
• Memakai data transaksi yang terkumpul untuk agregasi dan peramalan permintaan
• Mengurangi pekerjaan yang bergantung pada individu tertentu

Namun berlangganan layanan EDI saja tidak cukup. Data seperti kode produk perlu ditata, aturan operasional perlu disepakati dengan mitra dagang, dan data perlu dapat diimpor ke sistem internal yang ada.

Titik awal penerapan EDI bukan “produk mana yang dipakai”, melainkan meneliti berapa kali informasi yang sama dimasukkan dalam pekerjaan sekarang. Yang realistis adalah menemukan titik di mana orang mengangkut informasi di antara FAX, email, Excel, layar Web, dan sistem manajemen penjualan, lalu dari situ mengganti berurutan, ke integrasi data, pekerjaan yang volumenya besar dan terpola.

Untuk yang sedang meninjau integrasi data pemesanan

Jika ingin mengefisienkan pemesanan antarperusahaan, tetapi tidak tahu dari mana meninjau operasi FAX, email, dan Excel sekarang, alur pekerjaan perlu ditata lebih dulu.

Jika dicek dalam format apa informasi diterima dari mitra dagang, ke sistem internal mana dimasukkan, dan bagaimana dihubungkan ke stok, pengiriman, dan penagihan setelahnya, lingkup yang dapat diotomatisasi mulai terlihat.

Di KomuraSoft LLC, Anda dapat berkonsultasi tentang menata kondisi saat ini dan meninjau cara mewujudkan integrasi operasional, termasuk aplikasi bisnis Windows yang ada, CSV, berkas panjang tetap, basis data, dan sistem Web.

Tanpa berangkat dari penggantian menyeluruh, konfigurasi yang mempertahankan mekanisme sekarang sambil hanya mengurangi bagian input manual juga dapat ditinjau.

Referensi

• JIPDEC (Japan Information Economy and Society Promotion Association), Apa itu EDI. Tentang definisi EDI (perusahaan, lembaga pemerintah, dan sebagainya menghubungkan komputer lewat jaringan, lalu menukar slip dan dokumen secara otomatis sebagai data elektronik), definisi menurut JIS X 7011, mekanisme konversi timbal balik antara format khas tiap perusahaan dan format standar, serta bahwa gambar hasil pindai dan email teks biasa dibedakan dari data EDI.
• JIPDEC, Manfaat EDI dan perlunya standar EDI. Tentang efisiensi dan percepatan pekerjaan administrasi, pengiriman just-in-time, pemendekan lead time, penekanan stok, penghapusan kesalahan manusia, pemanfaatan untuk analisis produk laris, spend analysis, dan peramalan permintaan, bahwa tanpa mengikuti standar diperlukan mekanisme konversi per mitra dagang sehingga biayanya tidak sebanding, lima butir yang perlu disepakati (protokol komunikasi, aturan sintaksis, pesan dan kolom data, aturan operasional bisnis, aturan dasar transaksi), serta bahwa jika data yang diterima dicetak dan diproses orang, keadaannya tidak jauh berbeda dari FAX.
• Badan UKM Jepang, Digitalisasi pemesanan (EDI bersama untuk UKM). Tentang peningkatan efisiensi kerja, pengurangan kesalahan manusia, dan peningkatan kemampuan pencarian catatan transaksi lewat digitalisasi pemesanan, serta penyusunan “EDI bersama untuk UKM” yang menstandarkan pekerjaan pemesanan bagi UKM.
• Badan Digital Jepang, JP PINT (spesifikasi standar invoice elektronik). Tentang Badan Digital Jepang, sebagai Peppol Authority Jepang, yang mengelola dan menerbitkan spesifikasi standar invoice elektronik Jepang “JP PINT” yang ditukar di jaringan Peppol.

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.