Studi Kasus: Sistem Internal untuk Perusahaan Multi-Divisi

Permintaan yang masuk ke kami berbunyi singkat: "kami butuh satu sistem untuk semua divisi". Setelah dua pekan mengamati, masalahnya ternyata bukan ketiadaan sistem. Tiap divisi sudah punya, dan sebagian bekerja dengan baik untuk keperluannya sendiri. Yang tidak ada adalah jalan di antara mereka. Satu nomor pesanan yang sama muncul dengan tiga nama berbeda di tiga tempat, dan tidak ada satu pun orang yang bisa menjawab pertanyaan sederhana seperti "pesanan ini sekarang di mana" tanpa menelepon dua orang.

Kasus ini kami tulis apa adanya karena polanya berulang di hampir semua perusahaan yang tumbuh cepat: sistem tumbuh mengikuti divisi, bukan mengikuti pekerjaan. Identitas kliennya kami samarkan atas permintaan mereka.

Kondisi awal: lima divisi, lima cara kerja

Lima divisi yang terlibat: penjualan, operasional, gudang, keuangan, dan purna jual. Masing-masing rasional dalam pilihannya sendiri, dan justru itu yang membuat keadaan sulit diperbaiki dari dalam.

Penjualan bekerja di CRM berbayar yang dipilih karena mudah dipakai dari ponsel saat kunjungan.
Operasional memakai papan tugas daring dengan kolom yang disusun sendiri, ditambah grup chat untuk hal yang mendesak.
Gudang memakai spreadsheet bersama yang sudah berumur bertahun-tahun, dengan rumus yang hanya dipahami satu orang.
Keuangan memakai perangkat akuntansi yang tidak bisa diganggu gugat karena terkait pelaporan pajak.
Purna jual mencatat keluhan di formulir dan menyimpan lampirannya di penyimpanan awan.

Batas antar-divisi dijembatani manusia. Seseorang membaca dari satu layar dan mengetik ke layar lain. Jembatan seperti ini murah saat perusahaan kecil dan berubah jadi beban terbesar begitu volumenya naik.

Tiga gejala yang selalu muncul bersamaan

Angka yang sama tidak pernah sama. Jumlah pesanan menurut penjualan berbeda dengan menurut gudang, dan keduanya berbeda dengan menurut keuangan. Semuanya bisa dibenarkan, karena masing-masing menghitung pada titik yang berbeda. Tidak ada yang salah, tapi juga tidak ada yang bisa dipercaya sebagai angka tunggal.
Rapat jadi alat sinkronisasi. Rapat mingguan lintas divisi habis untuk menyamakan status, bukan mengambil keputusan.
Pengetahuan tersimpan di orang. Ketika satu orang cuti, satu alur berhenti. Ini risiko yang jarang ditulis di dokumen mana pun.

Selama status pekerjaan hanya ada di kepala orang dan di riwayat chat, perusahaan sedang menyewa ingatan karyawannya sebagai basis data.

Proses yang paling banyak memakan waktu

Kami tidak mulai dari daftar keinginan. Kami mulai dengan mengikuti satu pesanan dari awal sampai selesai, mencatat setiap kali datanya berpindah tangan. Metodenya sederhana dan bisa Anda lakukan sendiri: ambil satu transaksi nyata, gambar perjalanannya, dan tandai setiap titik di mana ada manusia yang menyalin data dari satu tempat ke tempat lain.

Hasil pemetaan itu menunjukkan empat titik yang paling mahal:

Serah terima dari penjualan ke operasional

Kesepakatan yang ditutup di lapangan diketik ulang ke papan tugas, sering dengan detail yang tidak lengkap karena penjual sudah berpindah ke calon pelanggan berikutnya. Selisih pemahaman di titik ini menghasilkan pekerjaan ulang di hilir, dan pekerjaan ulang selalu lebih mahal daripada mencatat dengan benar sejak awal.

Permintaan stok ke gudang

Dilakukan lewat chat. Tidak ada antrean, tidak ada prioritas, tidak ada jejak. Permintaan yang tenggelam di antara percakapan lain baru ketahuan saat pelanggan menagih.

Penagihan

Keuangan menunggu konfirmasi bahwa barang sudah dikirim, dan konfirmasi itu datang dalam bentuk yang berbeda-beda. Setiap hari tertundanya penagihan adalah uang yang menganggur di luar rekening perusahaan.

Keluhan yang butuh riwayat

Ketika pelanggan mengeluh, purna jual harus merangkai ulang cerita dari empat sumber. Waktu penyelesaian keluhan bukan ditentukan oleh sulitnya masalah, melainkan oleh lamanya mengumpulkan riwayat.

Urutan pengerjaan yang dipilih

Keputusan terbesar di proyek ini adalah tidak mengganti kelima sistem. Mengganti semuanya sekaligus berarti lima divisi berhenti bekerja normal pada saat yang sama, dan itu risiko yang tidak sebanding dengan manfaatnya.

Yang dibangun adalah lapisan di tengah: satu tempat di mana entitas inti perusahaan hidup, dan sistem-sistem lama menyambung ke sana secara bertahap.

Tahap satu: menyepakati entitas dan penamaan

Sebelum kode ditulis, satu pertanyaan harus dijawab bersama: apa itu "pesanan", kapan ia dianggap "selesai", dan apa saja status yang sah di antaranya. Pekerjaan ini terlihat seperti rapat yang membuang waktu dan sebenarnya adalah bagian paling menentukan dari seluruh proyek. Sistem yang dibangun di atas definisi yang belum disepakati akan menjadi tempat pertengkaran baru, hanya dengan tampilan yang lebih rapi.

Hasilnya satu halaman berisi daftar entitas, daftar status, dan pemilik tiap status. Satu halaman, bukan dokumen tebal, supaya benar-benar dibaca.

Tahap dua: satu alur ujung ke ujung, bukan satu divisi

Godaan berikutnya adalah mengerjakan divisi per divisi. Kami memilih sebaliknya: satu jenis pesanan yang paling sering terjadi, dikerjakan lengkap dari penjualan sampai penagihan. Sempit, tapi utuh.

Alasannya praktis. Sistem yang selesai untuk satu divisi tidak menghasilkan manfaat apa pun sampai divisi berikutnya ikut, sehingga dukungan internal habis sebelum hasilnya terlihat. Satu alur utuh, walau hanya untuk sebagian kecil pesanan, langsung membuktikan bahwa idenya bekerja.

Tahap tiga: menyambung sistem lama

Setelah alur inti berjalan, sistem lama disambungkan satu per satu, dengan aturan yang dipegang teguh: untuk tiap data, ada satu sistem yang berhak menjadi sumber kebenaran, dan sisanya hanya membaca. Tanpa aturan ini, dua sistem akan saling menimpa dan tidak ada yang tahu versi mana yang benar.

Perangkat akuntansi sengaja tidak disentuh sama sekali. Yang dibuat hanya jalur satu arah yang menyiapkan data siap unggah. Divisi keuangan tidak perlu mengubah cara kerjanya, dan risiko terhadap pelaporan pajak tetap nol.

Tahap empat: laporan lintas divisi

Baru setelah datanya menyatu, laporan dibuat. Membangun laporan sebelum data menyatu adalah kesalahan urutan yang paling sering kami lihat, dan hasilnya selalu sama: dashboard bagus yang isinya angka yang tidak dipercaya siapa pun.

Perlawanan internal dan cara mengatasinya

Bagian tersulit proyek ini tidak ada hubungannya dengan teknologi. Tiap divisi punya alasan yang masuk akal untuk menolak, dan alasan itu perlu ditanggapi, bukan diabaikan.

Keberatan	Yang sebenarnya dikhawatirkan	Yang kami lakukan
"Sistem lama kami sudah bagus"	Kehilangan alat yang sudah dikuasai	Tidak mengganti; hanya menyambungkan
"Ini menambah pekerjaan input"	Beban naik tanpa imbalan	Hapus satu input lama untuk tiap input baru
"Nanti semua kesalahan kami kelihatan"	Transparansi dipakai untuk menyalahkan	Kesepakatan tertulis: data dipakai memperbaiki proses, bukan menilai orang, selama masa transisi
"Kami tidak punya waktu"	Proyek ini tambahan di luar target	Jadwal mengikuti musim sepi tiap divisi
"Dulu pernah gagal"	Trauma proyek yang mangkrak	Rilis kecil yang terlihat hasilnya, bukan janji besar

Baris kedua adalah kuncinya. Kalau sistem baru hanya menambah pekerjaan tanpa mengurangi apa pun, ia akan ditinggalkan pelan-pelan, dan orang kembali ke spreadsheet lama tanpa mengumumkannya. Setiap kali kami meminta divisi mencatat sesuatu yang baru, kami mencari satu pencatatan lama yang bisa dihentikan pada hari yang sama.

Satu hal lagi yang berpengaruh besar: menaruh orang dari divisi, bukan dari manajemen, sebagai penentu bentuk layar mereka sendiri. Orang menerima sistem yang mereka ikut bentuk, dan menolak sistem yang diturunkan kepada mereka.

Hasil dan yang masih dikerjakan

Kami tidak akan menuliskan persentase penghematan untuk kasus ini, karena selama proyek berjalan perusahaan juga menambah orang dan mengubah beberapa kebijakan, sehingga tidak jujur menisbatkan seluruh perubahan angka pada sistem. Yang bisa kami sampaikan adalah perubahan yang jelas dan bisa diverifikasi di dalam perusahaan itu sendiri:

Pertanyaan "pesanan ini di mana" dijawab dari satu layar, tanpa menelepon siapa pun.
Serah terima antar-divisi meninggalkan jejak waktu. Ketika ada keterlambatan, yang dibahas adalah tahap mana yang macet, bukan siapa yang lalai.
Penagihan berjalan otomatis begitu status pengiriman tercatat, bukan menunggu seseorang mengingat.
Rapat mingguan berubah isi. Status sudah terbaca sebelum rapat, sehingga waktunya dipakai untuk kasus yang bermasalah saja.
Riwayat pelanggan lengkap di satu tempat, sehingga penanganan keluhan tidak lagi dimulai dengan penelusuran.

Yang belum selesai juga perlu disebut, karena proyek semacam ini tidak punya garis akhir yang rapi. Gudang masih memakai spreadsheet untuk sebagian barang tidak standar. Satu jenis pesanan khusus masih ditangani manual karena aturannya berubah beberapa kali dan belum stabil. Dan pekerjaan yang tidak pernah selesai: merawat sambungan ke sistem pihak ketiga, yang berubah tanpa memberi tahu siapa pun. Pengalaman kami menjaga sistem klien sudah menembus 38.000 jam maintenance, dan sebagian besar kerusakan memang berasal dari perubahan di hulu, bukan dari kode yang tiba-tiba rusak sendiri.

Kapan sistem internal custom bukan jawabannya

Kami menolak beberapa permintaan sejenis, dan alasannya layak Anda ketahui sebelum menganggarkan apa pun.

Kalau proses antar-divisi Anda masih berubah setiap bulan, membekukannya ke dalam sistem berarti membayar dua kali: sekali membangun, sekali membongkar. Rapikan prosesnya dulu di atas alat sederhana sampai bentuknya stabil beberapa bulan.

Kalau masalahnya sebenarnya satu divisi yang kelebihan beban, sistem lintas divisi hanya akan menyebarkan beban itu ke lebih banyak orang. Selesaikan di divisi tersebut lebih dulu.

Kalau kebutuhan Anda benar-benar standar dan tidak punya kekhususan, perangkat lunak siap pakai akan lebih murah dan lebih cepat, termasuk biaya perawatannya. Sistem custom masuk akal ketika ada cara kerja yang menjadi keunggulan Anda dan tidak dilayani produk mana pun di pasaran.

Dan kalau tidak ada satu orang di dalam perusahaan yang punya kewenangan memutuskan definisi lintas divisi, tunda proyeknya. Tanpa itu, pertanyaan seperti "kapan pesanan dianggap selesai" akan menggantung berbulan-bulan dan pembangunannya berhenti di tempat yang sama.

Kalau gejala di bagian awal tulisan ini terdengar familiar, langkah pertama yang bisa Anda kerjakan sendiri hari ini adalah memetakan perjalanan satu pesanan dan menandai titik salin-tempelnya. Cara kami membangun sistem semacam ini dijelaskan di halaman jasa pembuatan aplikasi, contoh pekerjaan lain ada di portofolio, dan kalau ingin peta alur Anda ditinjau bersama, kirim gambarannya lewat halaman kontak.