Memindahkan pesanan FAX ke Web ── merancang periode operasi ganda dan praktik migrasi bertahap

Pada artikel sebelumnya, “Apa itu EDI? Bagaimana EDI memudahkan pemesanan antarperusahaan”, kami menata mekanisme yang mengganti pekerjaan memasukkan ulang pesanan yang diterima lewat FAX atau email dengan pertukaran data antar sistem.

Artikel ini adalah kelanjutannya. Temanya maju satu langkah dari “memahami mekanismenya” ke cara bermigrasi.

Konsultasi “kami ingin memindahkan penerimaan pesanan FAX ke Web” biasanya berlanjut seperti ini.

“Tapi ada mitra dagang yang hanya bisa memakai FAX”

“Sistem manajemen penjualan ingin tetap dipakai seperti sekarang”

“Selama peralihan, pesanan tidak boleh berhenti”

Dengan kata lain, tantangan di lapangan bukan membangun sistem pesanan Web. Tantangannya adalah merancang periode ketika FAX masih ada, sambil secara bertahap pindah ke Web.

Artikel ini menata perpindahan pesanan FAX ke Web dengan empat poros: merancang periode operasi ganda, impor CSV sebagai bentuk perantara, menata master produk dan mitra dagang, serta cara melibatkan mitra dagang.

Pembaca yang dituju adalah staf penerimaan pesanan dan staf sistem informasi di perusahaan yang masih memasukkan pesanan yang datang lewat FAX atau email ke sistem manajemen penjualan secara manual. Setelah selesai membaca, yang diperoleh bukan cara membuat sistem pesanan Web itu sendiri, melainkan cara menyusun rencana migrasi: “dari mitra dagang mana, dalam urutan apa, dan apa yang diukur sambil pindah”. Jika ingin lebih dulu memahami gambaran mekanismenya, bacalah artikel EDI sebelumnya.

1. Kesimpulan lebih dulu

Poin utama saat merencanakan perpindahan pesanan FAX ke Web adalah sebagai berikut.

• Tempatkan tujuan bukan pada “menghapus FAX”, melainkan pada “mengurangi jumlah pesanan yang dimasukkan orang”
• Bertolak dari asumsi bahwa periode operasi ganda FAX dan Web pasti terjadi, lalu rancang lebih dulu durasinya dan cara mengukurnya
• Metode penerimaan (kanal) boleh lebih dari satu, tetapi pemrosesan pesanan internal disatukan menjadi satu alur
• Jangan langsung meminta input lewat layar Web; siapkan impor CSV sebagai bentuk perantara
• Karena layar pesanan Web menampilkan master produk dan mitra dagang apa adanya, tata master lebih dulu
• Jangan memindahkan semua mitra dagang sekaligus; klasifikasikan menurut volume dan tingkat kerja sama, lalu migrasikan berurutan

JIPDEC (Japan Information Economy and Society Promotion Association; lembaga yang dikenal karena mengoperasikan sistem PrivacyMark dan kode perusahaan standar) juga menyatakan, di halaman penjelasan proyek kode perusahaan standar “Manfaat EDI dan perlunya standar”, bahwa “jika pemrosesan manual serta penanganan FAX dan telepon masih tersisa, tenaga untuk itu tetap harus disediakan, sehingga otomatisasi dan mekanisasi 100% tidak tercapai dan efek efisiensi tidak diperoleh sepenuhnya”. Justru karena itu, periode operasi ganda tidak dibiarkan sebagai “sesuatu yang terpaksa terjadi”, melainkan rencana untuk memendekkannya sendiri yang dijadikan objek perancangan.

Peta pengetahuan artikel ini

Artikel ini membahas rancangan migrasi bertahap untuk pesanan FAX, dengan tujuan mengurangi jumlah pesanan yang diinput orang, bukan memindahkan semuanya ke Web sekaligus. Kanal penerimaan boleh lebih dari satu, tetapi pemrosesan pesanan internal disatukan menjadi satu alur; setelah menyisipkan impor CSV sebagai bentuk perantara, mitra dagang diklasifikasikan A, B, dan C menurut volume dan tingkat kerja sama, lalu pola dibuat di satu mitra percontohan dan diperluas. Pada periode operasi ganda, tenggat dan nilai sasaran ditetapkan secara angka, dan jumlah per kanal diukur setiap bulan memakai kolom kanal penerimaan. Tabel konversi kode dipegang oleh sisi sendiri yang lebih dulu mengetahui perubahan produk, dan setelah impor CSV berlanjut bentuk yang lebih tinggi seperti kode perusahaan standar dan EDI.

flowchart LR
    accTitle: Peta pengetahuan migrasi bertahap memindahkan pesanan FAX ke Web
    accDescr: Diagram rancangan migrasi bertahap yang menempatkan tujuan pada pengurangan jumlah pesanan yang diinput orang, lalu memendekkan periode operasi ganda berbatas waktu lewat impor CSV sebagai bentuk perantara serta klasifikasi mitra dan pembuatan pola di mitra percontohan
    fax_order_web_migration["perpindahan pesanan FAX ke Web (migrasi bertahap)"]
    dual_operation_period["periode operasi ganda"]
    transcription_volume_reduction_goal["tujuan mengurangi jumlah pesanan yang diinput orang"]
    all_at_once_web_migration["perpindahan total ke Web sekaligus"]
    indefinite_dual_operation["operasi ganda tanpa batas / menjadi tetap"]
    dual_operation_deadline_target["tenggat dan sasaran periode operasi ganda"]
    channel_migration_kpi["pengukuran jumlah per kanal"]
    receiving_channel_field["kolom kanal penerimaan"]
    csv_import_intermediate_form["impor CSV sebagai bentuk perantara"]
    csv_file_format_spec["kesepakatan format berkas CSV"]
    master_data_readiness["penataan master produk dan mitra dagang"]
    pilot_partner_approach["pembuatan pola dengan 1 mitra percontohan"]
    partner_classification["klasifikasi mitra dagang (A/B/C)"]
    unified_order_channel_processing["kanal penerimaan banyak, pemrosesan internal satu"]
    code_mapping_ownership_rule["aturan kepemilikan tabel konversi kode"]
    all_or_nothing_import_validation["kebijakan impor: hentikan semua jika ada error"]
    import_failure_notification["konfigurasi minimum notifikasi gagal impor"]
    cross_channel_rule_consistency["penyeragaman aturan operasional antar kanal"]
    duplicate_order_registration["registrasi ganda"]
    fax_handling_improvement["perbaikan cara menerima FAX"]
    edi["EDI (pertukaran data elektronik)"]
    standardized_business_code["kode perusahaan standar"]
    fax_order_web_migration -->|"mensyaratkan"| dual_operation_period
    transcription_volume_reduction_goal -->|"disarankan untuk"| fax_order_web_migration
    all_at_once_web_migration -->|"dapat menyebabkan"| indefinite_dual_operation
    transcription_volume_reduction_goal -->|"mencegah"| all_at_once_web_migration
    dual_operation_deadline_target -->|"mengurangi"| indefinite_dual_operation
    channel_migration_kpi -->|"menggunakan"| receiving_channel_field
    dual_operation_deadline_target -->|"diverifikasi dengan"| channel_migration_kpi
    csv_import_intermediate_form -->|"disarankan untuk"| fax_order_web_migration
    csv_import_intermediate_form -->|"menggunakan"| csv_file_format_spec
    csv_import_intermediate_form -->|"mensyaratkan"| master_data_readiness
    pilot_partner_approach -->|"mensyaratkan"| master_data_readiness
    partner_classification -->|"disarankan untuk"| fax_order_web_migration
    partner_classification -->|"sebaiknya didahului"| pilot_partner_approach
    unified_order_channel_processing -->|"disarankan untuk"| fax_order_web_migration
    code_mapping_ownership_rule -.->|"disarankan untuk"| csv_import_intermediate_form
    all_or_nothing_import_validation -.->|"disarankan untuk"| csv_import_intermediate_form
    all_or_nothing_import_validation -->|"mensyaratkan"| import_failure_notification
    cross_channel_rule_consistency -->|"disarankan untuk"| fax_order_web_migration
    cross_channel_rule_consistency -->|"mengurangi"| duplicate_order_registration
    fax_handling_improvement -->|"disarankan untuk"| dual_operation_period
    edi -->|"penerus dari"| csv_import_intermediate_form
    standardized_business_code -.->|"disarankan untuk"| edi
    partner_classification -->|"mencegah"| all_at_once_web_migration

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 23, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Mengapa perpindahan total ke Web sekaligus mudah gagal

Perpindahan pesanan FAX ke Web punya ciri yang tidak bisa diputuskan hanya dari kepentingan sistem internal. Yang mengirim pesanan adalah mitra dagang.

Cara mengumumkan ke semua mitra dagang “mulai bulan depan silakan pesan lewat Web” cenderung berujung pada kegagalan seperti berikut.

• Mitra dagang yang hanya bisa memesan lewat FAX berubah dari “pengecualian” menjadi “hambatan rencana”
• Keadaan tiap mitra dagang berbeda, tetapi tenggat yang sama dipaksakan
• Pesanan dari mitra yang tidak pindah tetap datang lewat FAX, sehingga operasi ganda menjadi tanpa batas waktu
• Penilaiannya menjadi “sudah pindah ke Web tetapi orang tidak berkurang”, lalu proyek berhenti

Penyebabnya adalah tujuan diletakkan pada “menghilangkan FAX”.

Jika tujuan diganti menjadi “mengurangi jumlah pesanan yang dimasukkan orang”, rencananya menjadi realistis. Misalnya, jika hanya mitra dagang teratas yang mencakup 70% pesanan yang pindah ke Web atau CSV, pekerjaan input tetap berkurang besar meskipun 30% sisanya masih FAX.

Bukan menggerakkan semuanya sekaligus, melainkan menggerakkan dulu dari yang efeknya besar, berurutan. Itulah dasar migrasi bertahap.

3. Wujud setelah migrasi ── pintu masuk banyak, pemrosesan internal satu

Sebelum merancang migrasi bertahap, gambar dulu bentuk yang dituju.

Intinya adalah memisahkan kanal penerimaan dari pemrosesan pesanan.

flowchart LR
    ORDER["Data pesanan bersama<br/>(format diseragamkan)"]
    BACK["Pemrosesan internal<br/>alokasi stok, pengiriman, penagihan"]
    subgraph CH["Kanal penerimaan"]
        FAX["FAX"]
        MAIL["Lampiran email"]
        CSV["Impor CSV"]
        WEB["Layar pesanan Web"]
    end
    FAX -->|"Staf memasukkan"| ORDER
    MAIL -->|"Staf memasukkan"| ORDER
    CSV -->|"Impor otomatis"| ORDER
    WEB -->|"Registrasi otomatis"| ORDER
    ORDER --> BACK

Berapa pun jenis kanal penerimaannya, jika format dan pemrosesan data pesanan setelah itu disatukan menjadi satu, proses lanjutan seperti stok, pengiriman, dan penagihan tetap berjalan secara bersama.

Sebaliknya, jika tiap kanal punya pemrosesan atau ledger sendiri, setiap kali kanal bertambah pekerjaan menjadi lebih rumit, dan beban operasi ganda terus naik.

Pesanan yang datang lewat FAX pun, pada saat staf memasukkannya, harus menjadi data pesanan yang sama dengan kanal lain. Migrasi dapat dikatakan sebagai pekerjaan mengurangi volume yang mengalir di baris “staf memasukkan” pada gambar ini, dan menambah volume yang mengalir di baris “impor otomatis” dan “registrasi otomatis”.

Sistem manajemen penjualan yang ada tidak harus diganti. Jika dapat dipastikan apakah pintu masuk data pesanan bisa ditambahkan (fungsi impor CSV, integrasi basis data, API, dan sebagainya), pekerjaan dapat dilanjutkan dengan mempertahankan mekanisme sekarang. Titik pemeriksaan ini sama dengan yang ditata di “Memeriksa koneksi ke sistem internal” pada artikel EDI sebelumnya.

4. Impor CSV sebagai bentuk perantara

Memindahkan mitra dagang langsung dari FAX ke input layar Web kadang terasa berat bagi mereka.

Dari sisi yang memesan, input layar Web berarti “memasukkan sekali lagi, ke layar pihak lain, pesanan yang sudah dibuat di sistem pemesanan atau Excel sendiri”. Jika mitra dagang sudah membuat data pesanan dengan sistemnya sendiri, menerima dan mengimpor data itu sebagai berkas lebih sedikit pekerjaannya bagi kedua belah pihak.

Karena itu, sebagai bentuk perantara, disiapkan impor CSV (atau Excel).

Tahap 1: menerima CSV sebagai lampiran email, lalu staf membacanya dengan fungsi impor
Tahap 2: mitra dagang mengunggah CSV dari halaman Web, lalu diimpor otomatis
Tahap 3: mitra dagang yang sudah terpola pindah ke layar pesanan Web atau EDI

Bahkan pada tahap 1, waktu input dan kesalahan penyalinan berkurang besar dibanding input manual sambil melihat surat pesanan. Perubahan di sisi mitra dagang hanya “mengganti yang dulu dikirim FAX menjadi lampiran email”, sehingga kerja sama lebih mudah didapat. Itu juga kelebihannya.

Saat merancang impor CSV, tetapkan setidaknya butir berikut.

Di antara keenam butir ini, yang paling sering diperdebatkan di lapangan adalah sistem kode. Apakah “mitra dagang mengirim dengan kode produk mereka” atau “mereka ubah dulu ke kode kita baru dikirim” menentukan siapa yang memegang tabel konversi. Dari penjualan muncul suara “lebih mudah jika mitra mengirim dengan kode kita”, sedangkan dari tim sistem informasi muncul suara “memegang tabel konversi per mitra adalah beban”.

Titik temunya adalah: tabel konversi dipegang oleh pihak yang lebih dulu mengetahui perubahan produk. Yang pertama tahu produk baru atau dihentikan adalah sisi sendiri, jadi jika konversi dilakukan di sisi sendiri, tidak perlu meminta semua mitra dagang “ganti tabel kode” setiap kali ada penambahan atau penghentian produk. Cara meminta mitra menghafal kode sendiri terasa ringan di awal, tetapi setiap kali ada perubahan produk, komunikasi harus dikirim ke sebanyak itu orang. Menyelesaikan bolak-balik ini sebelum migrasi menghindarkan keharusan menjelaskan ulang nanti “mengapa rancangannya seperti ini”.

Satu lagi yang langsung terkait operasional adalah cara mengembalikan error. Impor pada prinsipnya lebih aman “dihentikan jika seluruh berkas error” (jika satu baris pun tidak sah, tidak ada yang diimpor) daripada mengejar pesanan yang masuk sebagian. Namun itu hanya berlaku jika penghentian itu pasti sampai ke seseorang. Konfigurasi minimumnya seperti berikut.

• Notifikasi email ke internal ── kirim otomatis “impor gagal” ke milis staf penerimaan pesanan. Di subjek, nama berkas dan nama mitra dagang; di isi, nomor baris error dan penyebabnya (misalnya “kode produk ABC-123 tidak ada di master”).
• Riwayat impor di layar pengelolaan ── siapkan layar yang memperlihatkan berhasil, gagal, dan belum diproses dalam satu daftar. Meski email terlewat, melihat layar ini pagi-pagi sudah cukup untuk menyadarinya.
• Kontak ke mitra dagang ── pada awalnya jangan membalas otomatis; staf internal memeriksa isinya dulu baru menghubungi. Setelah maju ke unggah Web, error ditampilkan langsung di layar unggah.

Rancangan “error sudah ada di log, silakan dicek” tidak cocok untuk periode operasi ganda. Staf sudah penuh dengan pemrosesan FAX.

CSV tampak sederhana, tetapi format ini banyak jebakannya: encoding karakter, baris baru, penanganan koma dan tanda kutip. Poin teknis saat mengimplementasikan pemrosesan impor dirangkum di “Panduan praktis pemrosesan berkas CSV”.

Perlu dicatat, impor CSV bukan bentuk akhir, melainkan bentuk perantara. Definisi kolom dan sistem kode yang diputuskan di sini tetap menjadi fondasi untuk pesanan Web dan EDI setelahnya.

5. Tata dulu master produk dan mitra dagang

Pada penerimaan pesanan FAX, kekurangan master diserap oleh staf.

Misalnya, meski surat pesanan memakai nama produk lama, staf menafsirkannya sebagai “ini produk yang sekarang ini” lalu memasukkannya. Meski satuannya tertulis “case”, staf mengingat berapa isi per case dan mengonversinya.

Begitu pindah ke impor CSV atau pesanan Web, penafsiran itu dilakukan mesin. Lebih jauh, di layar pesanan Web, master produk langsung terlihat oleh mitra dagang.

Karena itu, sebelum migrasi setidaknya perlu ditata hal berikut.

• Penataan kode produk (pembersihan produk dihentikan, penggabungan duplikat, tabel korespondensi kode lama dan baru)
• Penyeragaman penulisan nama produk (apakah namanya layak ditunjukkan ke mitra dagang)
• Satuan dan isi kemasan (hubungan pcs, case, dan palet, serta kuantitas pesanan minimum)
• Kode mitra dagang dan kode tujuan kirim (penanganan jika satu mitra punya beberapa tujuan kirim)
• Di mana mengelola harga satuan yang berlaku dan syarat kontrak per mitra dagang

Yang penting di sini adalah jangan menunggu semua master sempurna baru mulai. Jika itu yang ditunggu, migrasi tidak pernah dimulai.

Yang realistis adalah menata dulu hanya lingkup produk dan tujuan kirim yang ditangani mitra dagang pertama (percontohan), lalu memperluas lingkup setiap kali mitra yang dimigrasikan bertambah. Pekerjaan menata master itu sendiri dimasukkan ke fase migrasi bertahap.

6. Merancang periode operasi ganda

Operasi ganda FAX dan Web (CSV) pasti terjadi selama periode migrasi. Jika dibiarkan tanpa rancangan, operasi ganda menjadi kebiasaan, dan keadaannya menjadi “pekerjaan bertambah sebesar kanal yang ditambahkan”.

Merancang periode operasi ganda, secara konkret, berarti memutuskan hal berikut.

6.1. Tetapkan durasi dan nilai sasaran

Tentukan secara angka “kapan, berapa persen jumlah pesanan yang akan diimpor otomatis”. Misalnya dalam bentuk “dalam 6 bulan, rasio pesanan FAX dari 70% menjadi 30%”.

Operasi ganda tanpa tenggat akan langsung menjadi tetap. Meski sasaran tidak tercapai, adanya tenggat mendorong tindakan memeriksa per mitra dagang “mengapa migrasi tidak maju”.

6.2. Ukur volume per kanal setiap bulan

Kemajuan migrasi dilacak dari jumlah, bukan dari perasaan.

• Jumlah pesanan per kanal (FAX, lampiran email, CSV, Web)
• Jumlah pesanan yang diinput manual dan waktu yang dibutuhkan
• Jumlah error impor dan penyebabnya
• Jumlah koreksi input dan registrasi ganda

Ini cara berpikir yang sama dengan indikator yang perlu diukur setelah penerapan yang disebut di artikel sebelumnya. Mengukur terpisah per kanal membuat terlihat “mitra dagang mana yang paling besar efeknya jika didorong”.

Masalahnya adalah bagaimana mengumpulkannya. Jika diputuskan “mari dihitung setiap bulan” tanpa mekanisme, penghitungan berhenti di bulan pertama. Yang andal adalah menambahkan satu kolom pengukuran pada data pesanan itu sendiri.

Jika kolom tidak bisa ditambahkan ke sistem manajemen penjualan yang ada, simpan log pemrosesan impor dan layar input di tabel terpisah, lalu agregasikan dari situ. Apa pun caranya, cara mengukur diputuskan sebelum migrasi dimulai. Karena kriteria penentuan fase (bab 8) yang dibahas nanti adalah rasio kanal, jika rasio tidak bisa diambil, tidak bisa diputuskan apakah maju ke fase berikutnya atau berhenti.

6.3. Seragamkan aturan operasional antar kanal

Kekacauan selama periode operasi ganda mudah terjadi jika aturan bisnis berbeda per kanal.

• Apakah jam cut-off pesanan sama antara FAX dan Web
• Perubahan dan pembatalan pesanan diterima di kanal mana (jika perubahan pesanan yang diterima lewat Web diterima lewat FAX, diperlukan pencocokan)
• Apakah cara pemberitahuan saat stok kosong berbeda per kanal
• Apakah nomor pesanan unik lintas kanal (diperlukan untuk mendeteksi registrasi ganda)

Khususnya pola “pesan lewat Web, lalu segera diubah lewat telepon atau FAX” pasti terjadi. Tentukan lebih dulu di kanal mana perubahan diterima, dan siapa yang memperbaiki data yang mana.

6.4. Cara menerima FAX juga dijadikan objek perbaikan

Selama periode operasi ganda, FAX tetap ada. Jika berangkat dari asumsi itu tetap ada, pemrosesan sisi FAX juga menjadi objek perbaikan.

• Terima FAX di mesin multifungsi, ubah ke PDF, dan hentikan pengelolaan kertas
• Kumpulkan PDF yang diterima ke folder pesanan, dan kelola status pemrosesan (belum diproses, sudah diinput, ditahan)
• Hubungkan asli FAX (PDF) setelah diinput dengan data pesanan lewat nomor pesanan, agar bisa dicocokkan kemudian

Jika berpikir “FAX akan hilang nanti jadi tidak usah disentuh”, beban selama periode operasi ganda tidak turun. Sampai migrasi selesai, pemrosesan FAX diperlakukan sebagai satu kanal yang bermuara ke data pesanan yang sama.

7. Cara melibatkan mitra dagang

Berhasil tidaknya migrasi bertahap lebih ditentukan oleh pendekatan ke mitra dagang daripada pekerjaan internal.

7.1. Klasifikasikan mitra dagang

Jangan memperlakukan semua mitra dagang sama; klasifikasikan dulu.

Yang menentukan efek adalah A dan B. Memaksa mitra C bergerak hanya menambah biaya, jadi kepada mereka boleh dinyatakan dengan tegas “FAX pun akan tetap kami terima”.

7.2. Pilih satu mitra percontohan

Jangan memigrasikan beberapa mitra secara paralel dari awal; tetapkan dulu operasionalnya dengan satu mitra. Kriteria pemilihannya sama dengan artikel sebelumnya.

• Volume transaksi tinggi, sehingga efeknya mudah diukur
• Banyak pesanan yang terpola
• Komunikasi antar staf lancar, dan ada pemahaman terhadap integrasi sistem

Dengan mitra percontohan, buat “pola” seperti format CSV, cara kontak saat error, tabel korespondensi master, dan dokumen pengantar, lalu pola itu dipakai ulang mulai mitra kedua.

7.3. Sampaikan dengan manfaat bagi mitra

Dari sisi mitra dagang, perubahan cara memesan adalah permintaan demi kepentingan kita. Pengantar dijelaskan bukan dengan efisiensi kita, melainkan dengan manfaat bagi mereka.

• Konfirmasi pesanan segera kembali, sehingga telepon “apakah sudah sampai” tidak perlu
• Salah kirim dan selisih kuantitas karena salah baca berkurang
• Riwayat pesanan bisa dilihat sendiri, sehingga pesanan berulang lebih mudah (untuk pesanan Web)
• Pekerjaan mengirim FAX dan pengiriman ulang karena error transmisi hilang

Selain itu, perhatian praktis juga berpengaruh.

• Ringkas prosedur operasi dalam satu lembar panduan (skala yang cukup dijelaskan dengan beberapa layar)
• Nyatakan tanggal mulai dan periode penggunaan bersama (“mulai bulan X kami juga menerima lewat Web. FAX masih bisa dipakai untuk sementara”)
• Untuk beberapa kali pertama, terima baik yang dikirim FAX maupun Web, dan tanggapi pertanyaan dengan segera

Perlu dicatat, tidak disarankan mengumumkan dari awal “FAX akan dihentikan pada bulan X”. Lebih baik membicarakan tenggat baru setelah migrasi maju dan mitra yang tersisa tinggal sedikit, agar hubungan tidak rusak.

Tentang digitalisasi pemesanan di UKM, Badan UKM Jepang memperkenalkan inisiatif standardisasi termasuk EDI bersama, beserta efeknya. Jika asosiasi industri atau mitra dagang utama sudah mendukung standar itu, pertimbangkan juga opsi menyesuaikan ke standar, bukan ke format sendiri.

8. Contoh model migrasi bertahap

Isi sejauh ini disusun sebagai model linimasa. Durasinya hanyalah contoh, dan berubah menurut jumlah mitra dagang serta organisasi internal.

“Menata kondisi saat ini” pada fase 0 dapat memakai langsung penyusunan daftar metode pemesanan yang diperkenalkan di artikel sebelumnya.

Selain itu, jika ragu apakah pengelolaan pesanan itu sendiri harus dipindah ke sistem Web atau tetap sebagai aplikasi desktop, kerangka keputusannya ditata di “Haruskah aplikasi Windows dipindah ke Web”. Perpindahan kanal penerimaan ke Web dan perpindahan sistem internal ke Web dapat diputuskan secara terpisah.

9. Kendala yang sering terjadi dan cara mengatasinya

Terakhir, dirangkum kendala yang mudah terjadi pada migrasi di lapangan.

Ringkasan

Memindahkan pesanan FAX ke Web lebih merupakan pekerjaan merancang periode migrasi, bukan pekerjaan membuat sistem.

• Tempatkan tujuan pada “pengurangan jumlah pesanan yang diinput orang”, bukan “penghapusan FAX”
• Kanal penerimaan boleh lebih dari satu, tetapi data dan pemrosesan pesanan internal disatukan menjadi satu
• Jangan langsung meminta input layar Web; sisipkan impor CSV sebagai bentuk perantara
• Penataan master dilanjutkan secara bertahap, mulai dari lingkup mitra dagang yang pertama dimigrasikan
• Beri tenggat dan nilai sasaran pada periode operasi ganda, dan ukur kemajuan dengan jumlah per kanal
• Klasifikasikan mitra dagang menurut volume dan tingkat kerja sama, buat pola dengan satu mitra percontohan, baru perluas

Seperti yang ditata di artikel sebelumnya, efek EDI atau pesanan Web ditentukan oleh seberapa jauh data yang diterima dapat dialirkan ke pekerjaan internal. Merancang migrasi berarti merencanakan, dalam urutan yang wajar, peningkatan proporsi pesanan yang bermuara ke aliran itu.

Untuk yang sedang meninjau perpindahan pemesanan ke Web

Jika sedang meninjau penerimaan pesanan FAX tetapi ragu harus mulai dari mana — penyesuaian dengan mitra dagang, koneksi ke sistem manajemen penjualan yang ada, cara menyusun format CSV dan master — yang diperlukan lebih dulu adalah menata jumlah pesanan per kanal saat ini.

Di KomuraSoft LLC, Anda dapat berkonsultasi tentang perancangan dan implementasi impor CSV serta integrasi pesanan Web dengan memanfaatkan aplikasi bisnis Windows dan basis data yang ada, maupun tentang menata rencana migrasi itu sendiri.

Tanpa berangkat dari penggantian menyeluruh, konfigurasi yang mempertahankan mekanisme manajemen penjualan sekarang sambil menambahkan kanal penerimaan secara bertahap juga dapat ditinjau.

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.