Sistem yang Dapat Digunakan dan Mudah Digunakan di Indonesia

Keberhasilan proyek berarti menyelesaikan sesuai jadwal dan sistem berfungsi sesuai kebutuhan. Hasilnya adalah terciptanya sistem yang dapat digunakan di Indonesia, tetapi sistem yang mudah digunakan berarti memiliki tata letak layar yang ramah sehingga operasi yang diinginkan langsung terlihat dan mudah dipahami.

Gap Umum antara Sistem dan Operasional Lapangan

Mengenai penyimpangan (gap) antara sistem dan operasional lapangan, tanpa adanya pemikiran untuk menutupi sebagian melalui operasional, pengenalan sistem tidak akan berhasil. Berikut adalah gap yang sering terjadi saat mengimplementasikan sistem bisnis di Indonesia:

• • Contoh 1
    Penginputan hasil produksi di pabrik dilakukan oleh staf departemen manajemen produksi pada pukul 10:00 pagi keesokan harinya, sementara di lapangan, shift malam langsung mengirimkan produk jadi. Akibatnya, sistem menunjukkan kekurangan stok produk sehingga Delivery Order (surat pengiriman) tidak dapat diterbitkan.
  • Contoh 2
    Dalam perusahaan perdagangan, saat memesan barang, meskipun barang sudah tiba, jika invoice belum diterima, pendaftaran pembelian tidak dapat dilakukan di sistem. Akibatnya, barang yang sudah diterima tidak tercatat sebagai stok di sistem dan proses pengiriman tidak dapat dilakukan.
  • Contoh 3
    Di lapangan, biasanya instruksi pengiriman untuk keesokan hari dicetak sehari sebelumnya untuk persiapan, tetapi jika sistem mengasumsikan instruksi pengiriman berdasarkan alokasi stok, instruksi pengiriman tidak dapat diterbitkan karena kekurangan stok.
  • Contoh 4
    Ketika instruksi pengiriman untuk 20 unit dikeluarkan dari pesanan 100 unit, pengguna ingin mengetahui 80 unit sebagai "sisa pesanan yang belum diberi instruksi pengiriman". Namun, di sistem, sisa pesanan tetap 0 hingga proses pengiriman selesai, dan baru setelah itu sisa 80 unit dapat diketahui.

Dalam alur pemrosesan sistem "Pesanan - Alokasi - Instruksi Pengiriman - Pengiriman Selesai", jika pesanan dan instruksi pengiriman hanya dapat dibagi secara 1:1, meskipun ini benar secara sistem, hal ini menimbulkan ketidaknyamanan dalam operasional.

• Contoh 5
  Di pabrik, saat memesan bahan, jika invoice dari pemasok datang secara bulanan pada bulan berikutnya, nomor invoice tidak diketahui dalam bulan berjalan. Akibatnya, bahan yang langsung digunakan tidak dapat didaftarkan ke invoice, sehingga data penerimaan-pengeluaran untuk perhitungan biaya produksi tidak tercipta.
• Contoh 6
  Dalam proses sistem dari pendaftaran pesanan hingga pengiriman dan penerbitan invoice, revisi selalu terjadi sebelum penutupan akhir bulan. Namun, jika revisi ini tidak selesai, inventaris fisik tidak dapat tercermin di sistem.
• Contoh 7
  Ada kasus di mana lapangan tidak dapat mengikuti alur yang diasumsikan sistem, seperti membaca barcode tiket barang untuk pengeluaran dan pengembalian bahan, atau memasukkan hasil setiap kali terjadi NG atau barang khusus, serta menempelkan tiket barang.
• Contoh 8
  Ketika kesalahan ditemukan saat memasukkan hasil inventaris fisik dan ingin memperbaiki hasil produksi bulan tersebut, jika lot sudah mengalir ke pelanggan, pembatalan harus dilakukan berurutan mulai dari invoice dan Delivery Order di hilir. Namun, ini menyebabkan nomor invoice atau Delivery Order baru diterbitkan, memengaruhi pengelolaan dokumen pelanggan atau mitra, sehingga revisi tidak dapat dilakukan.

Definisi "Dapat Digunakan" dan "Mudah Digunakan"

Industri manufaktur Jepang di Indonesia tertinggal jauh dalam sistematisasi dibandingkan China atau Thailand. Baru belakangan ini penggantian proses manual berbasis Excel dengan sistem bisnis menjadi hal yang umum. Namun, perlu dicatat bahwa sistematisasi tidak selalu memberikan hasil positif.
Definisi saya tentang "sistem yang dapat digunakan" atau "sistem yang mudah digunakan" adalah:

Namun, "mudah digunakan" hanya ada jika "dapat digunakan" sudah terpenuhi, dan tidak sebaliknya.

Ada kritik seperti itu, tetapi untuk mencapai level di mana pekerjaan dapat dijalankan dengan sistem, baik pihak yang mengimplementasikan maupun yang menerima implementasi membutuhkan energi yang cukup besar.

Bagaimana Mengimplementasikan Sistem yang Dapat Digunakan?

Siapa pun yang memutuskan membayar untuk mengimplementasikan sistem pasti merasa khawatir, "Apakah proyek ini akan berhasil?" Pada dasarnya, "proyek yang berhasil" dapat diringkas menjadi:

Kedua poin ini adalah intinya.

Apakah Bisa Selesai dalam Periode yang Direncanakan?

"Apakah bisa selesai dalam periode yang ditentukan?" adalah masalah saat pengenalan sistem. Cutover sistem (di Indonesia lebih sering disebut Go Live?) biasanya disesuaikan dengan awal tahun fiskal seperti Januari atau April. Jika tidak selesai tepat waktu, input ganda dengan sistem lama akan berlangsung lama, meningkatkan beban kerja dan menghambat pekerjaan utama, yang berarti kerugian peluang.
Penyebab keterlambatan jadwal antara lain:

Kelewatan pencatatan tugas jarang terjadi pada perangkat lunak paket karena tugasnya sudah jelas, tetapi pada sistem yang melibatkan pengembangan, kesalahan estimasi jam kerja bisa terjadi.
Langkah pengenalan sistem dimulai dari menerima Request For Proposal (RFP) dari pelanggan, lalu membuat proposal dan estimasi berdasarkan RFP. Namun, pada tahap ini, kebutuhan pengguna belum 100% terdengar, sehingga estimasi jam kerja sering kali dilakukan secara kasar.

Oleh karena itu, saat implementasi dimulai dan definisi kebutuhan awal dilakukan, sering kali muncul pengecualian tak terduga yang meningkatkan jam kerja.
Selain itu, ada kelewatan pertimbangan hari libur. Seperti diketahui, di negara Islam, periode puasa bergeser setiap tahun, dan kesalahan memperhitungkan ini bisa terjadi. Selama puasa, staf pelanggan pulang lebih awal dan tidak bisa dipaksakan. Juga, di Indonesia, pemilu atau demo bisa menyebabkan pabrik tutup setengah hari, yang sulit diprediksi.

Apakah Sistem Berfungsi dengan Baik?

Ini adalah masalah setelah sistem mulai beroperasi, atau dengan kata lain, "Apakah pekerjaan dapat dijalankan dengan baik oleh sistem?" Jika saat memilih perangkat lunak paket, pertimbangan cermat dilakukan tentang kecocokan dengan kebutuhan perusahaan, risiko tertentu bisa dihindari.
Penyebab sistem tidak berfungsi dengan baik antara lain:

Perangkat lunak paket dirancang dengan fungsi umum untuk digunakan di banyak perusahaan, sehingga 80% mungkin cocok (FIT), tetapi 20% tetap menjadi gap. Jika 20% ini terkait dengan inti pekerjaan, itu menjadi masalah besar dan menyebabkan kerugian investasi.
Saya pernah melihat kasus di mana sistem hanya mendukung perhitungan harga rata-rata bergerak dan metode FIFO, tetapi pekerjaan sebenarnya harus menggunakan metode rata-rata total sesuai instruksi dari Jepang, sehingga sistem tidak dapat digunakan apa adanya.
Juga, meskipun ada rencana untuk mengelola lot dengan tiket barang, input hasil tidak dilakukan pada lot yang benar, input dihentikan karena lot tidak ditemukan, atau akurasi inventaris buruk sehingga lot tanpa tiket barang berserakan di lapangan—hal yang biasa di pabrik Indonesia.
Jika alur bisnis baru dirancang secara teoretis dan aplikasi dibuat sesuai itu, lapangan mungkin tidak dapat mengikuti setelah beroperasi.

Untuk Menghindari Risiko

Sebenarnya, titik dan faktor yang cenderung menyebabkan keterlambatan dalam jadwal pengenalan sistem dapat diprediksi.
Saat membuat jadwal, dengan memecah jadwal utama dari bulanan ke mingguan dan harian, serta memecah tugas secara vertikal, tugas dan urutan waktu dapat dilihat secara horizontal dan vertikal, sehingga lebih mudah dibayangkan.

Faktor yang dapat menyebabkan keterlambatan jadwal meliputi masalah dari sisi pengenalan dan sisi pelanggan:

Dalam jadwal keseluruhan, bagian biru adalah proses definisi kebutuhan untuk mengidentifikasi bagian yang sesuai (Fit) dan gap antara permintaan pengguna dan spesifikasi standar sistem, serta menentukan alur pekerjaan dan aplikasi. Bagian merah adalah bagian yang rentan keterlambatan dan dapat mendorong tugas fase berikutnya.

Saat mengenalkan sistem, situasi pelanggan bisa berupa peluncuran baru, pemrosesan manual dengan Excel, atau ada sistem lama. Secara kasar, pabrik baru paling mudah diimplementasikan, sedangkan yang tersulit adalah pabrik dengan sistem terpisah di setiap departemen. Membawa sistem baru ke situasi dengan sistem lama yang berjalan akan menyebabkan banyak gesekan selama proyek.
Jika ada sistem ERP lama, penggantian total akan membuat kondisi sama untuk semua departemen, sehingga meski terpaksa, input akan dilakukan. Namun, jika sistem seperti P/O untuk pembelian, paket akuntansi lokal murah, atau sistem khusus untuk tugas tertentu terpisah dan dijalankan dalam departemen tanpa komunikasi antar-departemen, itu yang tersulit.
Dengan menyadari hal ini sebelumnya dan menjalankan proyek, serta berbagi status aktual terhadap rencana dalam rapat mingguan, risiko keterlambatan dapat dikurangi.

Bagaimana Mengimplementasikan Sistem yang Mudah Digunakan?

Setelah mengatasi berbagai kesulitan dan pekerjaan dapat dijalankan dengan sistem, pasti muncul permintaan baru dari pengguna akhir.

Mudah digunakan berarti "memiliki fungsi yang mudah dioperasikan dan nyaman", tetapi prasyarat utamanya adalah tata letak layar yang ramah sehingga "operasi yang diinginkan" langsung terlihat.

Saya pikir ketiga hal ini adalah spesifikasi wajib di Indonesia. Selain itu, untuk menyesuaikan dengan praktik bisnis dan sistem pajak khas Indonesia, diperlukan kustomisasi tertentu.

Ini adalah contoh fungsi yang akan memudahkan pengguna akhir perusahaan Jepang di Indonesia, tetapi sebaliknya, tanpa fungsi ini pun sistem tetap bisa digunakan.
Secara sederhana, perlu ada garis pemisah antara fungsi nyaman yang diimplementasikan di sistem dan yang ditangani secara manual. Untuk menentukan garis ini, pengguna akhir harus memahami bahwa "kustomisasi membutuhkan jam kerja".
Di Indonesia, terlalu banyak orang yang ingin semuanya dilakukan gratis.