Pola alur kerja untuk tim operasi yang menghemat waktu

Mengapa alur kerja operasi terus dibangun ulang

Kebanyakan tim operasi tidak mulai dari pola bersama. Mereka mulai dari proses terakhir yang berhasil, menyalinnya, mengganti beberapa label, lalu lanjut. Permintaan cuti berubah menjadi permintaan peralatan. Formulir pembelian berubah menjadi formulir pemasok. Namanya berubah, tetapi pekerjaan di bawahnya biasanya sangat mirip.

Itulah mengapa alur yang sama dibangun berulang kali. Satu tim menyebut langkah itu "persetujuan manajer." Tim lain menyebutnya "review." Tim ketiga menambahkan notifikasi email dan menganggapnya proses baru. Di atas kertas, alur itu tampak berbeda. Dalam praktik, sebagian besar mengikuti jalur yang sama: seseorang mengajukan permintaan, seseorang memeriksa, seseorang menyetujui, dan seseorang diberi tahu.

Masalah yang lebih besar adalah aturan sebenarnya sering tidak tertulis. Aturan itu hidup di thread chat, email lama, catatan spreadsheet, atau di kepala satu orang yang berpengalaman. Saat seseorang mencoba mengubah itu menjadi alat, mereka mengisi celah dari ingatan. Hasilnya bekerja untuk beberapa kasus, tapi rusak pada kasus lain.

Perbedaan kecil menciptakan keterlambatan yang lebih besar dari yang tim perkirakan. Satu field bersifat opsional di satu formulir dan wajib di formulir lain. Satu tim memberi tahu bagian keuangan sebelum persetujuan, sementara tim lain menunggu sampai akhir. Seorang reviewer berpikir mereka bisa mengedit permintaan, tapi formulir terkunci. Dua orang mengira orang lain yang akan menutup tugas. Tidak ada yang tampak serius sendiri-sendiri. Bersama-sama, itu menciptakan pengerjaan ulang, serah terima yang lambat, dan klarifikasi terus-menerus.

Kejadian ini sering muncul saat tim membangun alat internal dengan cepat menggunakan aplikasi tanpa kode. Kecepatan membantu, tetapi kecepatan tanpa pola bersama sering menghasilkan lima versi dari alur yang sama. Penghemat waktu sejati bukan hanya membangun lebih cepat. Itu menggunakan kembali blok alur kerja yang jelas alih-alih mendesain ulang setiap proses dari awal.

Setelah tim melihat bahwa sebagian besar permintaan dibangun dari beberapa langkah yang sama, setiap alur baru berhenti terlihat seperti masalah desain yang benar-benar baru.

Lima blok yang paling sering digunakan tim

Sebagian besar alur operasi dapat direduksi menjadi lima blok bangunan: submit, review, approve, notify, dan close. Berbagai tim mungkin menggunakan nama berbeda, tetapi strukturnya tetap familiar. Seseorang meminta sesuatu, seseorang memeriksa, seseorang memutuskan, orang-orang diberitahu, dan tugas diselesaikan.

Submit adalah tempat permintaan dimulai. Langkah ini menentukan nada untuk semua yang mengikuti. Jika formulir intake samar, sisa proses berubah menjadi tebak-tebakan dan pesan tindak lanjut.

Review bukan keputusan akhir. Itu pemeriksaan kualitas. Langkah ini memastikan permintaan lengkap, detail yang tepat terlampir, dan tidak ada yang hilang sebelum sampai pada pengambil keputusan.

Approve adalah titik keputusan. Seorang manajer, pemimpin tim, atau pemilik mengatakan ya, tidak, atau mengembalikan permintaan berdasarkan anggaran, prioritas, kebijakan, atau risiko.

Notify mencegah orang mengejar pembaruan lewat chat atau email. Pemohon, reviewer, approver, dan tim yang mengerjakan pekerjaan harus tahu apa yang berubah dan apakah mereka perlu bertindak.

Close menandai proses selesai. Ini langkah yang sering dilewatkan banyak tim. Menutup berarti pekerjaan selesai, status final, dan tidak ada yang harus lagi memperlakukan item itu seperti tugas terbuka.

Blok-blok ini bekerja karena masing-masing memiliki tugas yang jelas. Submit mengumpulkan permintaan. Review memeriksa kualitas. Approve mengambil keputusan. Notify membagikan hasil. Close menandai proses selesai.

Saat tim memisahkan tugas-tugas itu, mereka bisa menggunakannya kembali di banyak alur, dari permintaan akses hingga onboarding pemasok. Di platform tanpa kode seperti AppMaster, itu sering berarti memakai kembali logika formulir, aturan status, dan notifikasi alih-alih membangun ulang setiap proses dari nol.

Mulai dari submit dan tangkap permintaan dengan jelas

Langkah submit membentuk semuanya yang terjadi berikutnya. Jika permintaan pertama berantakan, setiap review, approval, dan pembaruan memakan waktu lebih lama.

Mulailah dengan menentukan siapa yang boleh membuat permintaan. Kadang itu berarti semua orang di perusahaan. Kadang harus dibatasi ke pemimpin tim, koordinator, atau vendor yang disetujui. Keputusan itu memengaruhi izin, desain formulir, dan seberapa banyak panduan yang dibutuhkan formulir.

Jaga formulir tetap singkat. Orang harus bisa membukanya, memahaminya cepat, dan menyelesaikannya tanpa menebak. Jika sebuah field tidak membantu seseorang untuk mereview, menyetujui, memenuhi, atau melaporkan permintaan nanti, kemungkinan besar itu tidak perlu ada.

Kebanyakan formulir permintaan hanya butuh beberapa hal dasar:

• apa yang diminta
• mengapa dibutuhkan
• kapan dibutuhkan
• siapa yang meminta
• file atau catatan yang dibutuhkan

Itu biasanya cukup untuk menggerakkan pekerjaan maju. Formulir panjang sering menghasilkan data yang lebih buruk, bukan lebih baik, karena orang terburu-buru, melewatkan detail, atau memilih jawaban acak hanya untuk menyelesaikannya.

Kejelasan setelah pengajuan juga penting. Pemohon harus tahu apa yang terjadi selanjutnya. Konfirmasi sederhana dapat mencegah banyak kebingungan dengan menjelaskan siapa yang meninjau permintaan, status awalnya, dan kapan menunggu pembaruan.

Pemakaian ulang membantu di sini juga. Banyak tim membuat formulir terpisah untuk variasi kecil dari permintaan yang sama dan kemudian menyia-nyiakan waktu memeliharanya. Dalam banyak kasus, satu formulir bersama dengan field jenis permintaan bekerja lebih baik. Permintaan perlengkapan kantor, permintaan akses perangkat lunak, dan permintaan peralatan kecil sering mengikuti pola awal yang sama.

Jika Anda membangunnya di aplikasi tanpa kode, tujuannya bukan mengumpulkan lebih banyak data. Tujuannya mengumpulkan sedikit detail yang dibutuhkan orang berikutnya agar mereka bisa bertindak dengan cepat dan percaya diri.

Review dan approve bukan langkah yang sama

Banyak tim menganggap review dan approval sebagai satu tindakan. Itu terdengar lebih sederhana, tetapi biasanya menciptakan kebingungan. Satu orang memeriksa apakah permintaan lengkap. Orang lain memutuskan apakah tim harus melanjutkan sama sekali.

Review tentang kualitas dan kelengkapan. Approval adalah jawaban ya atau tidak.

Saat langkah itu terpisah, tanggung jawab menjadi lebih jelas. Reviewer memeriksa detail, menandai informasi yang hilang, dan mengembalikan permintaan jika tidak siap. Approver melihat anggaran, risiko, jadwal, atau kebijakan dan memutuskan apakah permintaan itu harus dilanjutkan.

Langkah review harus menjawab pertanyaan seperti:

• Apakah semua informasi yang dibutuhkan sudah diisi?
• Apakah tanggal, angka, dan lampiran benar?
• Apakah permintaan mengikuti proses dasar?

Langkah approval harus menjawab pertanyaan berbeda: apakah kita menerima permintaan ini atau tidak?

Pemecahan itu penting karena menjaga keputusan tetap bersih. Seorang reviewer di bagian keuangan mungkin memastikan bahwa permintaan pembelian memiliki kutipan yang benar. Kepala departemen kemudian menyetujui atau menolak pengeluaran. Jika orang yang sama melakukan keduanya tanpa aturan yang jelas, permintaan cenderung macet atau bolak-balik.

Juga membantu menentukan di muka siapa yang bisa mengirim kerja kembali untuk diedit. Di banyak tim, reviewer dapat mengembalikan permintaan untuk perbaikan, sementara approver hanya dapat menyetujui atau menolak. Itu mencegah masalah umum di mana approver senior mulai mengedit detail alih-alih mengambil keputusan yang seharusnya mereka buat.

Jaga aturan penolakan dan pengerjaan ulang sederhana. Jika permintaan bisa diperbaiki, tandai sebagai "perlu perbaikan" dan kirim kembali dengan catatan singkat. Jika tidak boleh dilanjutkan sama sekali, tandai sebagai ditolak. Hasil itu tidak boleh dicampur.

Selalu catat mengapa permintaan disetujui atau ditolak. Alasan singkat membantu pemohon memperbaiki pengajuan berikutnya dan memberi tim riwayat yang jelas. Bahkan field komentar wajib saat menolak bisa mencegah banyak pertanyaan berulang nanti.

Notifikasi dan penutupan tanpa ujung longgar

Sebuah alur kerja hanya terasa selesai ketika orang yang tepat tahu apa yang berubah dan catatannya lengkap. Di sinilah banyak tim kehilangan waktu. Mereka mengirim terlalu banyak peringatan, meninggalkan langkah terakhir samar, dan kemudian butuh pesan ekstra untuk memastikan pekerjaan benar-benar selesai.

Notifikasi harus terjadi ketika sesuatu berubah secara bermakna, bukan pada setiap klik. Permintaan baru, keputusan, tugas terblokir, atau item selesai biasanya pantas mendapat pemberitahuan. Pembaruan internal kecil sering tidak perlu. Jika setiap langkah memicu pesan, orang berhenti memperhatikan dan melewatkan pemberitahuan yang penting.

Saat seseorang diberi tahu, pesan harus spesifik. Harus langsung menjawab tiga pertanyaan: apa yang berubah, siapa yang perlu bertindak, dan kapan. "Permintaan pembelian disetujui. Bagian Keuangan perlu memesan sebelum Jumat" jauh lebih baik daripada "Permintaan diperbarui."

Penutupan harus sama jelasnya. Harus menyisakan satu catatan akhir dengan pemilik untuk tindakan terakhir, tanggal penutupan, status akhir seperti disetujui, ditolak, selesai, atau dibatalkan, dan catatan singkat jika ada pengecualian atau tindak lanjut.

Simpan catatan akhir itu di satu tempat. Jika keputusan ada di email, tanggal ada di chat, dan status di spreadsheet, proses itu tidak benar-benar ditutup. Orang berikutnya masih harus menanyakan apa yang terjadi.

Contoh sederhana permintaan pembelian menunjukkan mengapa ini penting. Setelah disetujui, pemohon harus mendapat pembaruan yang jelas. Setelah barang dipesan, alur harus ditutup dengan nama pembeli, tanggal pesanan, dan status akhir. Dengan begitu tidak ada yang perlu mengirim pesan "Hanya cek apakah ini sudah ditangani" minggu depan.

Jika Anda membangunnya ke dalam aplikasi internal, buat langkah close wajib, bukan opsional. Aturan kecil itu mengurangi ujung longgar dan menghemat banyak pekerjaan tindak lanjut.

Cara mengubah satu proses menjadi pola yang dapat digunakan ulang

Mulailah dengan satu proses yang sering ditangani tim. Pilih sesuatu yang umum, bukan yang aneh. Pekerjaan yang berulang menunjukkan di mana pola akan menghemat paling banyak waktu.

Tulis proses saat ini dengan bahasa sederhana, persis seperti orang melakukannya hari ini. Sederhana saja. "Karyawan mengirim permintaan, manajer memeriksa detail, keuangan menyetujui, pemohon mendapat pembaruan, kasus ditutup" lebih berguna sekarang daripada diagram yang rapi.

Kemudian kelompokkan tiap langkah ke salah satu dari lima blok: submit, review, approve, notify, atau close. Di sinilah proses menjadi dapat digunakan ulang. Daripada memperlakukan tiap alur sebagai kasus khusus, Anda mulai melihat struktur yang sama di bawahnya.

Cara yang baik menguji tiap langkah adalah dengan menanyakan beberapa pertanyaan dasar: Siapa memulainya? Siapa pemiliknya selanjutnya? Keputusan atau tindakan apa yang terjadi di sini? Hasil apa yang harus ada saat langkah selesai? Siapa yang perlu tahu setelah itu?

Pertanyaan-pertanyaan itu mendefinisikan baik pemilik maupun hasil yang diharapkan untuk setiap blok. Jika sebuah langkah tidak punya pemilik jelas, biasanya mandek. Jika tidak punya hasil jelas, orang terus bertanya apakah sudah selesai.

Contohnya, langkah review tidak boleh sekadar berarti "seseorang melihatnya." Itu bisa berarti "ketua tim memeriksa bahwa semua detail yang dibutuhkan ada." Langkah approval bisa berarti "kepala departemen memberikan ya atau tidak." Langkah close bisa berarti "permintaan ditandai selesai dan disimpan untuk pelaporan." Label yang jelas membuat pola lebih mudah digunakan ulang.

Sebelum menerapkannya secara luas, uji pola itu dengan satu permintaan baru-baru ini. Gunakan kasus nyata, bukan yang dibuat-buat. Permintaan nyata mengungkap field yang hilang, serah terima yang tidak jelas, dan notifikasi yang terlambat.

Jika uji berhasil, gunakan struktur yang sama pada alur serupa. Permintaan perjalanan, permintaan pembelian, dan permintaan akses perangkat lunak mungkin membutuhkan formulir berbeda, tetapi seringkali berbagi blok alur yang sama.

Di sinilah platform seperti AppMaster bisa membantu secara praktis. Jika strukturnya sudah jelas, Anda bisa memetakan blok-blok itu ke model data, logika bisnis, status, dan notifikasi tanpa membangun ulang seluruh alur setiap kali.

Contoh: alur permintaan pembelian sederhana

Permintaan pembelian perangkat lunak adalah contoh yang baik karena mudah dipahami dan masih mencakup blok yang sama yang digunakan banyak tim setiap hari: submit, review, approve, notify, dan close.

Seorang karyawan membutuhkan alat desain atau aplikasi pelaporan baru. Mereka mengajukan permintaan dengan nama perangkat lunak, alasan bisnis, perkiraan biaya, dan kode anggaran jika mereka tahu. Permintaan yang kuat juga mencantumkan siapa yang butuh akses dan seberapa cepat.

Operasi tidak langsung menyetujui perangkat. Pertama, seseorang meninjau permintaan dan memeriksa apakah kebutuhan jelas dan apakah detail anggaran benar. Jika ada yang hilang, permintaan dikembalikan untuk klarifikasi alih-alih bergerak maju dalam kondisi lemah.

Versi alur yang rapi mungkin terlihat seperti ini:

• permintaan baru diajukan
• review operasi selesai
• manajer disetujui atau ditolak
• IT diberi tahu dan akses ditetapkan
• permintaan ditutup setelah konfirmasi

Langkah manajer harus tetap sederhana. Manajer tidak ada untuk memasukkan kembali detail atau mengejar informasi yang hilang. Mereka memutuskan apakah pembelian masuk akal untuk peran, tim, dan anggaran, dan meninggalkan alasan singkat jika menolak.

Setelah disetujui, IT mendapat detail yang dibutuhkan untuk bertindak, seperti nama karyawan, nama perangkat lunak, jenis lisensi, dan tanggal penyelesaian. IT kemudian membeli atau menetapkan lisensi dan menandai permintaan siap untuk konfirmasi.

Permintaan tidak boleh ditutup saat IT mengklik "selesai." Itu harus ditutup hanya setelah karyawan mengonfirmasi mereka bisa masuk dan menggunakan alat. Pemeriksaan terakhir ini mencegah masalah umum: tiket terlihat selesai di catatan, tetapi orang tersebut masih tidak memiliki akses.

Di aplikasi tanpa kode, alur ini bisa dibuat dengan formulir, beberapa aturan status, dan pesan otomatis antar tim. Nama perangkat lunak, approver, atau pemilik anggaran mungkin berubah, tetapi polanya tetap sama.

Kesalahan umum yang memperlambat tim

Masalah kecil pada alur kerja jarang terlihat serius pada awalnya. Permintaan masih bergerak, email masih dikirim, dan seseorang masih klik setujui. Tetapi setelah satu atau dua minggu, celah-celah itu berubah menjadi keterlambatan, pengerjaan ulang, dan kebingungan.

Satu kesalahan umum adalah menambahkan terlalu banyak persetujuan untuk pekerjaan berisiko rendah. Jika permintaan perlengkapan kantor kecil memerlukan rantai yang sama seperti kontrak pemasok besar, orang berhenti mempercayai proses. Mereka menunggu terlalu lama atau mencari jalan pintas.

Kesalahan lain adalah mencampur review dan approval. Reviewer memeriksa apakah permintaan lengkap atau masuk akal. Approver membuat keputusan. Ketika orang yang sama melakukan keduanya tanpa sengaja, menjadi sulit memastikan apakah permintaan benar-benar diperiksa atau sekadar dipaksa lewat.

Notifikasi dapat menciptakan kebisingan daripada kejelasan. Jika setiap pembaruan dikirim ke semua orang, kebanyakan orang berhenti memperhatikan. Lalu satu pesan yang penting terlewat.

Nama status yang samar juga menyebabkan masalah. Label seperti "In Progress," "Pending," dan "Under Review" sering tumpang tindih. Orang membaca berbeda-beda. Proses yang bersih menggunakan status yang menunjukkan persis di mana pekerjaan berada dan apa yang harus terjadi selanjutnya.

Beberapa tanda peringatan yang muncul awal:

• permintaan sederhana memakan waktu hampir sama dengan yang kompleks
• staf terus menanyakan siapa pemilik langkah berikutnya
• orang menindaklanjuti lewat chat karena status tidak jelas
• item yang ditutup masih ada di daftar tugas seseorang
• laporan tidak sesuai dengan apa yang dipikirkan tim

Kesalahan besar terakhir adalah menganggap "tertutup" adalah akhir ketika pembersihan manual masih perlu dilakukan. Permintaan keuangan mungkin ditandai selesai sebelum catatan disimpan, pemohon diberi tahu, atau tugas terkait diarsipkan. Itu meninggalkan ujung longgar dan membuat pelaporan tidak dapat diandalkan.

Tujuannya bukan menambah lebih banyak langkah. Tujuannya membuat tiap langkah jelas, perlu, dan mudah digunakan ulang. Alur yang lebih cepat biasanya datang dari menghilangkan kebingungan, bukan menambah kontrol.

Pemeriksaan cepat sebelum menggunakan ulang pola

Sebelum menyalin alur ke proses baru, berhenti sejenak dan periksa hal dasar.

Mulailah dengan kepemilikan. Setiap langkah harus dimiliki oleh satu orang atau satu peran, bukan grup yang samar. Jika semua orang bisa bertindak, tidak ada yang merasa bertanggung jawab.

Pastikan alur bisa mundur ketika diperlukan. Permintaan nyata sering tidak lengkap. Reviewer mungkin butuh detail yang hilang, jumlah yang dikoreksi, atau lampiran baru. Jika pilihan hanya menyetujui atau menolak, orang mulai mengakali sistem lewat chat dan email.

Jaga entri data ketat. Field wajib harus hanya mencakup apa yang benar-benar dibutuhkan langkah berikutnya. Jika permintaan pembelian butuh pemasok, jumlah, dan alasan, jangan paksa lima field tambahan hanya karena mungkin berguna nanti.

Periksa setiap notifikasi juga. Notifikasi harus memicu tindakan jelas, mengonfirmasi hasil yang jelas, memperingatkan jika sesuatu macet, atau menutup lingkar untuk pemohon. Jika tidak melakukan hal-hal itu, kemungkinan itu hanya kebisingan.

Terakhir, buat status mudah dimengerti sekilas. Seseorang yang membuka permintaan tidak seharusnya membaca seluruh riwayat untuk tahu apa yang terjadi. Status sederhana seperti Submitted, In Review, Needs Fixes, Approved, dan Closed biasanya cukup.

Mengubah pola menjadi alat nyata

Tempat terbaik untuk memulai bukanlah proses terbesar Anda. Pilih satu pola yang tim gunakan setiap minggu dan sudah mereka kenal. Permintaan cuti, permintaan pembelian, serah terima insiden, atau persetujuan konten cukup untuk membuktikan apa yang bekerja.

Jaga versi pertama kecil. Jika orang bisa mengajukan permintaan, orang yang tepat bisa meninjaunya, dan semua orang mendapat hasil yang jelas, Anda sudah punya sesuatu yang berguna. Itu lebih penting daripada membangun sistem sempurna di hari pertama.

Langkah praktis berikutnya adalah mengubah pola itu menjadi aplikasi internal kecil. Aplikasi web cocok untuk tim yang bekerja di meja. Aplikasi mobile membantu ketika permintaan terjadi saat bergerak, seperti pemeriksaan lapangan, kunjungan toko, atau tugas gudang.

Bangun versi pertama dalam tiga bagian. Definisikan data yang perlu ditangkap. Pemetakan logika setelah pengajuan, termasuk review, approval, dan pengembalian. Lalu tambahkan langkah serah terima, seperti notifikasi, pembaruan status, dan keadaan penutupan yang jelas.

Jika Anda ingin membangun itu tanpa menulis semuanya sendiri, AppMaster adalah salah satu opsi untuk membuat alat internal lengkap dengan logika backend, aplikasi web, dan aplikasi mobile dari pengaturan yang sama. Keuntungan utamanya bukan hanya kecepatan. Itu bisa menggunakan kembali struktur yang sama di banyak proses internal setelah polanya jelas.

Saat alur pertama aktif, jangan buru-buru membangun ulang semuanya. Amati bagaimana orang menggunakannya selama satu atau dua minggu. Perhatikan di mana mereka berhenti, apa yang mereka lewati, dan field mana yang membuat bingung.

Lalu salin apa yang berhasil ke proses berikutnya. Gunakan kembali aturan submit, logika approval, dan struktur notifikasi yang sama bila masuk akal. Begitulah blok alur kerja yang dapat digunakan ulang berubah menjadi sistem operasi andal untuk tim, satu proses pada satu waktu.