Alur kerja web dan seluler untuk tim kantor dan lapangan

Mengapa satu alur kerja bersama sering gagal

Satu alur kerja untuk web dan seluler terdengar rapi. Dalam praktiknya, itu sering menimbulkan gesekan.

Staf kantor dan staf lapangan biasanya melakukan jenis pekerjaan yang berbeda. Orang di meja punya layar besar, keyboard, dan waktu untuk meninjau detail. Mereka mungkin perlu membandingkan catatan, memeriksa riwayat, mengedit formulir panjang, dan berpindah antar tab sebelum mengambil keputusan. Pekerjaan itu cocok di desktop karena memberi ruang dan konteks.

Staf lapangan bekerja di tengah kesibukan lain. Mereka mungkin berada di luar, berbicara dengan pelanggan, berjalan antar pekerjaan, atau memperbarui catatan dengan satu tangan memegang ponsel. Dalam momen itu, kecepatan lebih penting daripada detail. Mereka perlu mengambil foto, mengonfirmasi status, menyetujui tugas, atau menambahkan catatan singkat dalam hitungan detik.

Ketika kedua grup mendapatkan antarmuka yang sama, kedua sisi dirugikan. Antarmuka bergaya desktop di mobile terasa penuh dan lambat. Layar yang dibuat untuk mobile di desktop sering menyembunyikan terlalu banyak konteks dan membuat pekerjaan kantor canggung.

Masalah umum mudah dikenali. Pengguna mobile melihat terlalu banyak bidang untuk tugas yang hanya butuh beberapa tindakan cepat. Pengguna kantor mendapat terlalu sedikit riwayat dan detail untuk meninjau pekerjaan dengan benar. Langkah-langkah tambahan ditambahkan untuk memenuhi kebutuhan satu tim, lalu memperlambat tim lain.

Masalahnya bukan data bersama. Tim jelas harus berbagi data yang sama. Masalahnya adalah memaksa mereka berbagi layar yang sama, urutan yang sama, dan tingkat detail yang sama. Desain alur kerja yang baik menjaga satu sumber kebenaran, tetapi memberi setiap grup langkah yang sesuai dengan cara mereka bekerja.

Apa yang cocok di desktop

Jika sebuah tugas butuh ruang, perbandingan, atau tinjauan teliti, biarkan di desktop.

Contoh yang bagus adalah penjadwalan. Seorang manajer sering perlu melihat seluruh tim, pekerjaan terbuka, waktu, dan konflik sekaligus. Itu jauh lebih mudah di layar besar daripada di ponsel.

Pengeditan detail juga cocok di desktop. Ketika seseorang harus mengisi banyak bidang, memeriksa catatan, memperbaiki kesalahan, atau memperbarui beberapa catatan dalam satu waktu, keyboard dan tata letak yang lebih lebar membuat pekerjaan lebih cepat dan akurat.

Desktop biasanya tempat yang tepat untuk:

• penjadwalan dan perencanaan beban kerja
• formulir panjang dan pengeditan catatan rinci
• tinjauan dokumen dan laporan
• peran, pengaturan, izin, dan riwayat audit

Tinjauan dokumen adalah tugas desktop yang kuat. Membaca laporan, membandingkan versi, atau memeriksa apakah sesuatu sudah lengkap membutuhkan fokus. Di mobile, orang cenderung membaca sekilas dan melewatkan detail kecil.

Pengaturan dan kontrol izin juga sebaiknya tetap di tangan staf kantor di desktop. Perubahan peran, tingkat akses, dan aturan persetujuan memengaruhi semua orang, jadi tindakan ini butuh layar yang lebih jelas, peringatan, dan catatan lengkap tentang siapa yang mengubah apa.

Pemeriksaan audit mengikuti pola yang sama. Orang sering perlu menelusuri rantai peristiwa, membandingkan cap waktu, meninjau perubahan status, dan memastikan siapa yang menyetujui langkah itu. Itu lebih mudah ketika catatan penuh terlihat.

Aturan sederhana bekerja: jika tugas itu rinci, berisiko, atau jarang dilakukan, mulai dengan menaruhnya di desktop. Pekerja lapangan bisa memperbarui status pekerjaan dari ponsel, tetapi memindahkan lima janji dan menata ulang hari sebaiknya dilakukan di meja.

Apa yang cocok di mobile

Mobile harus menangani pekerjaan yang terjadi di saat itu juga. Mobile terbaik untuk tindakan cepat, bukan sesi peninjauan panjang atau pengaturan data berat.

Pikirkan apa yang dibutuhkan staf lapangan di lokasi kerja, di gudang, atau saat kunjungan pelanggan. Mereka perlu menangkap bukti, mengonfirmasi kemajuan, dan melanjutkan pekerjaan dengan cepat.

Tindakan mobile yang paling berguna sederhana: ambil foto, tambahkan catatan singkat, kumpulkan tanda tangan, dan tandai pekerjaan sebagai mulai atau selesai. Masing-masing harus membutuhkan hanya beberapa ketukan.

Jika seseorang harus mengetik pembaruan panjang di ponsel, proses itu terlalu berat. Gunakan kotak centang, bidang teks pendek, catatan suara jika sesuai, dan tombol tindakan yang jelas seperti Approve, Reject, Arrived, Delayed, atau Complete.

Mobile bekerja paling baik ketika tindakan tetap kecil dan jelas:

• tangkapan foto, catatan, dan tanda tangan yang cepat
• pembaruan status satu atau dua ketukan
• persetujuan singkat dengan label yang jelas
• notifikasi hanya ketika seseorang benar-benar perlu merespons

Persetujuan di mobile harus dibatasi pada keputusan yang bisa dibuat dengan cepat. Seorang manajer mungkin menyetujui kunjungan, mengonfirmasi pengiriman, atau menerima perubahan waktu dari notifikasi. Mereka tidak seharusnya membuka lima layar untuk melakukannya.

Notifikasi juga perlu ditahan. Kirimkan untuk perubahan jadwal, informasi yang hilang, pekerjaan yang ditolak, atau apa pun yang menghalangi langkah berikutnya. Jika setiap pembaruan kecil membuat notifikasi dorong, orang akan berhenti memperhatikan.

Tes sederhana membantu: bayangkan teknisi menyelesaikan kunjungan di tengah hujan, sinyal lemah, dan hanya satu tangan yang bebas. Bisakah mereka mengunggah foto, menambahkan catatan singkat, mendapatkan tanda tangan pelanggan, dan menandai tugas selesai dalam waktu kurang dari satu menit? Jika ya, alur mobile mungkin sudah melakukan tugasnya.

Peta alur mulai dari hasil akhir

Alur kerja yang baik dimulai dari akhir. Sebelum Anda memetakan layar atau menetapkan tugas, tentukan apa arti selesai.

Status akhir itu bisa berupa pekerjaan layanan selesai, kunjungan yang disetujui, atau catatan siap tagihan tanpa detail yang hilang. Setelah itu jelas, kerjakan mundur. Jika hasil akhir membutuhkan catatan pelanggan, foto, perubahan status, dan persetujuan manajer, setiap bagian harus punya pemilik dan momen yang jelas ketika ditambahkan.

Cara praktis memetakan alur adalah mendefinisikan catatan akhir terlebih dahulu, lalu tandai setiap serah terima antara staf kantor dan lapangan. Setelah itu, tetapkan kepemilikan untuk setiap titik data, hilangkan tempat di mana informasi yang sama diketik dua kali, dan simpan setiap pembaruan di dalam satu catatan pekerjaan bersama.

Catatan bersama itu lebih penting daripada yang sering tim duga. Desktop dan mobile bisa terlihat sangat berbeda, tetapi tetap harus menunjuk pada pekerjaan, kunjungan, atau tugas yang sama. Jika kantor mengedit satu versi sementara tim lapangan memperbarui versi lain, kesalahan cepat muncul.

Contohnya, jika pekerja lapangan mengubah pekerjaan dari "On site" menjadi "Completed," tim kantor harus segera melihat status yang sama di tampilan mereka. Pekerja tidak boleh mengirim pesan lalu memasukkan pembaruan yang sama lagi nanti.

Setelah alur terlihat benar di atas kertas, uji satu contoh nyata dari awal sampai akhir. Jangan gunakan demo sempurna. Gunakan pekerjaan biasa dan amati di mana orang ragu, bertanya, atau memasukkan informasi ulang.

Titik masalah umum sudah sering terlihat: serah terima tanpa pemilik jelas, field wajib yang hanya dapat dilihat satu tim, label status yang ditafsirkan berbeda, atau catatan yang disalin ke chat, email, dan aplikasi.

Buat serah terima menjadi jelas

Alur kerja hanya berfungsi ketika serah terima jelas. Jika orang tidak yakin siapa yang memegang langkah berikutnya, pekerjaan terhenti, tanggal mundur, dan tugas yang sama diedit oleh banyak orang.

Mulai dengan pembuatan tugas. Di banyak tim, catatan pertama sebaiknya dibuat oleh orang yang paling punya konteks, biasanya seseorang di meja. Mereka bisa memasukkan detail pelanggan, catatan pekerjaan, file, dan tenggat waktu tanpa terburu-buru. Staf lapangan tidak seharusnya membangun ulang informasi itu di ponsel saat berada di lokasi.

Setelah itu, tentukan siapa yang boleh mengubah apa. Tanggal, anggaran, ruang lingkup, dan janji kepada pelanggan biasanya menjadi tanggung jawab manajer, dispatcher, atau pemimpin kantor. Pengguna mobile bisa menambahkan catatan, mengonfirmasi kedatangan, mengunggah foto, dan menandai pekerjaan selesai, tetapi mereka tidak seharusnya bisa diam-diam mengubah pekerjaan yang memengaruhi tim lain.

Nama status sama pentingnya. Hindari label yang terlalu umum sehingga tidak berguna. Setiap status harus memberi tahu apa yang sudah terjadi dan apa yang harus terjadi selanjutnya.

Alur status sederhana bisa terlihat seperti ini:

• New request - tim kantor meninjau pekerjaan
• Scheduled - tanggal ditetapkan dan pekerja ditugaskan
• On site - staf lapangan telah tiba dan mulai bekerja
• Waiting approval - tim kantor atau pelanggan harus mengonfirmasi langkah berikutnya
• Complete - pekerjaan selesai dan siap untuk penagihan atau penutupan

Kata-kata yang tepat kurang penting dibandingkan makna bersama. Semua orang harus membaca status dengan cara yang sama.

Berguna juga untuk menampilkan tindakan berikutnya setelah setiap pembaruan. Jika pekerja lapangan menandai pekerjaan sebagai "Waiting approval," sistem harus jelas menunjukkan bahwa manajer kini perlu meninjau biaya, waktu, atau pekerjaan tambahan. Jika tim kantor mengubah tanggal pekerjaan, pekerja harus melihat pembaruan itu segera, bukan mengetahuinya kemudian lewat telepon.

Contoh layanan lapangan sederhana

Bayangkan sebuah perusahaan pemanas dan pendingin kecil. Tim kantor menangani penjadwalan, detail pelanggan, penawaran, dan penagihan di desktop. Teknisi di van hanya perlu pekerjaan berikutnya, alamat, nama kontak, dan cara sederhana melaporkan apa yang terjadi.

Hari dimulai di kantor. Seorang koordinator memesan pekerjaan perbaikan di desktop karena ada lebih banyak yang harus dimasukkan: riwayat pelanggan, jenis layanan, jendela waktu, catatan suku cadang, dan komentar internal. Pekerjaan semacam itu lebih mudah dengan keyboard penuh, tampilan lebih besar, dan akses ke beberapa catatan sekaligus.

Setelah pemesanan disimpan, teknisi mendapat pekerjaan di mobile. Tampilan ponsel tetap singkat dan jelas. Menampilkan alamat, waktu pekerjaan, nomor telepon pelanggan, dan daftar periksa kecil untuk tiba, pekerjaan dimulai, dan pekerjaan selesai. Teknisi tidak perlu semua detail back-office.

Di lokasi, teknisi menemukan panel kontrol yang rusak. Alih-alih menulis laporan panjang, mereka menggunakan aplikasi mobile untuk mengambil beberapa foto, menambahkan catatan singkat, dan menandai bahwa pekerjaan tambahan diperlukan. Itu memakan waktu kurang dari satu menit, yang penting saat mereka berdiri di lorong atau bekerja di luar.

Di kantor, atau dari dasbor manajer, seseorang meninjau permintaan di desktop. Mereka membandingkan foto, memeriksa penawaran awal, mengonfirmasi harga, dan menyetujui pekerjaan tambahan. Desktop lebih baik di sini karena keputusan butuh lebih banyak konteks.

Setelah disetujui, teknisi melihat pembaruan di mobile dan menyelesaikan pekerjaan. Saat mereka menandai selesai, semua orang melihat status akhir yang sama. Tim kantor tahu kunjungan selesai, manajer dapat melihat pekerjaan yang disetujui sudah selesai, catatan pelanggan siap untuk penagihan, dan teknisi bisa pindah ke pekerjaan berikutnya tanpa panggilan telepon.

Itulah nilai memisahkan alur berdasarkan perangkat. Desktop menangani pekerjaan administratif berat. Mobile menangani aksi cepat di lapangan.

Kesalahan umum yang harus dihindari

Sebagian besar masalah alur kerja muncul dari mencoba membuat kedua perangkat melakukan pekerjaan yang sama.

Salah satu kesalahan umum adalah mengubah aplikasi mobile menjadi formulir desktop penuh. Jika pekerja lapangan harus menggulir puluhan input hanya untuk mengunggah foto dan menandai kunjungan selesai, proses melambat dan kesalahan meningkat.

Kesalahan lain adalah menggunakan nama status yang berbeda di desktop dan mobile. Jika kantor melihat "Awaiting approval" sementara aplikasi menampilkan "Pending review," orang mulai menebak-nebak. Label yang sama penting karena serah terima bergantung padanya.

Entri data ganda juga sumber gesekan. Alamat pelanggan, nomor pekerjaan, atau catatan dari langkah sebelumnya seharusnya terbawa otomatis. Mengetik ulang membuang waktu dan menciptakan ketidakcocokan.

Tim juga sering menyembunyikan detail penting di balik terlalu banyak layar. Jika teknisi butuh empat ketukan untuk menemukan instruksi lokasi atau status persetujuan saat ini, mereka mungkin melewatkan sesuatu. Hal-hal dasar harus terlihat segera.

Banyak tim juga meluncurkan terlalu luas, terlalu cepat. Proses yang terlihat baik dalam rapat bisa gagal di van, di lokasi kerja, atau dengan sinyal lemah. Pilot singkat di dunia nyata menunjukkan di mana orang benar-benar terjebak.

Aturan berguna: jangan meniru proses desktop ke mobile. Pangkas untuk situasi itu. Pertahankan hanya apa yang membantu orang menyelesaikan tugas di tempat mereka berada.

Pemeriksaan cepat sebelum peluncuran

Sebelum diluncurkan, uji alur dengan pengguna nyata, bukan hanya orang yang merancangnya. Proses bisa terlihat jelas di atas kertas tapi tetap rusak begitu admin kantor sibuk atau pekerja lapangan mencoba menggunakannya tergesa-gesa.

Mulai dengan tugas utama yang paling sering dilakukan tiap grup. Jika pengguna baru tidak bisa menyelesaikannya tanpa penjelasan panjang, alurnya belum siap.

Periksa beberapa dasar:

• Dapatkah pengguna baru menyelesaikan tugas utama dari awal sampai akhir tanpa bantuan?
• Dapatkah staf kantor melihat pekerjaan yang hilang, terlambat, atau belum ditugaskan dalam satu tampilan?
• Apakah setiap persetujuan meninggalkan catatan jelas siapa yang menyetujui, kapan, dan apa yang berubah?
• Apakah pembaruan mobile kembali ke satu tempat bersama, bukan tersebar di teks, email, dan catatan aplikasi?
• Dapatkah seseorang memperbaiki kesalahan sederhana, seperti status yang salah atau foto yang masuk ke pekerjaan yang salah, tanpa dukungan admin?

Pemeriksaan ini terdengar kecil, tapi mereka menangkap masalah mahal. Pekerja lapangan mungkin bisa mengirim pembaruan, tetapi jika tim kantor tidak bisa melihatnya segera, serah terima masih gagal. Persetujuan mungkin secara teknis bekerja, tetapi jika tidak ada yang bisa menelusurinya nanti, sengketa jadi lebih sulit diselesaikan.

Kasus uji sederhana membantu. Buat satu pekerjaan palsu, kirim ke mobile, setujui, ubah status, tambahkan kesalahan, lalu perbaiki. Amati berapa lama itu berlangsung di desktop dan ponsel. Jika satu langkah terasa lambat atau membingungkan dalam tes, akan terasa lebih buruk di hari sibuk.

Perhatikan juga pemulihan dari kesalahan. Orang menekan tombol yang salah, memilih pelanggan yang salah, atau mengunggah catatan yang keliru. Desain alur kerja yang baik tidak menganggap pengguna sempurna. Desain membuat kesalahan kecil mudah dibatalkan.

Bangun, uji, lalu kembangkan

Mulai kecil. Pilih satu tim, satu alur kerja, dan satu tujuan yang jelas. Jika Anda mencoba mengubah setiap layar untuk setiap peran sekaligus, sulit melihat apa yang benar-benar bekerja.

Pilot yang kuat bisa melibatkan satu koordinator kantor dan satu kru lapangan yang menggunakan proses pekerjaan yang sama dengan cara berbeda. Sisi desktop menangani penjadwalan, pengeditan, dan pengecualian. Sisi mobile menangani tangkapan cepat, persetujuan, dan pembaruan status.

Jangan hanya mengandalkan opini. Lacak beberapa metrik sederhana: waktu untuk menyelesaikan tugas, jumlah kesalahan atau detail yang hilang, tugas yang terhenti, dan titik di mana pengguna beralih ke panggilan atau pesan.

Kemudian amati orang menggunakannya. Seorang manajer mungkin bilang layar desktop baik, tetapi penggunaan nyata bisa menunjukkan terlalu banyak klik. Pekerja lapangan mungkin bilang aplikasi mobile sederhana, tetapi di bawah sinar matahari atau sinyal lemah, satu langkah ekstra bisa jadi masalah.

Ubah desain berdasarkan penggunaan nyata, bukan tebakan. Perbaikan kecil sering paling berarti: formulir lebih pendek, tombol lebih besar, bidang wajib lebih sedikit, atau label status lebih jelas.

Jaga setiap putaran pengujian pendek. Satu atau dua minggu biasanya cukup untuk melihat pola. Lalu putuskan apakah mempertahankan alur, merevisi, atau memperluas ke tim lain.

Jika Anda ingin membuat prototipe kedua sisi dengan cepat, platform seperti Koder.ai bisa membantu. Platform itu memungkinkan tim membuat aplikasi web, server, dan mobile dari chat, yang berguna saat Anda ingin menguji alur admin desktop dan alur lapangan mobile tanpa menunggu pembangunan tradisional yang lama.

Rencana peluncuran yang paling aman sederhana: uji satu proses, ukur, perbaiki titik lemah, dan baru kemudian kembangkan. Dengan begitu Anda mendapatkan alur kerja yang benar-benar akan digunakan orang.