Mendigitalkan atau Membangun Ulang Proses? Kerangka Sederhana

Mengapa keputusan ini lebih sulit dari yang terlihat

Saat sebuah tim menemukan alur kerja manual, langkah yang tampak jelas adalah memasukannya ke perangkat lunak agar lebih cepat. Itu terdengar masuk akal, tetapi bisa mengunci keputusan buruk. Perangkat lunak hanya mengulangi apa yang Anda minta untuk diulang. Jika proses berisi persetujuan berlebih, entri data ganda, atau solusi sementara lama, alat itu bisa membuat masalah tersebut terasa resmi.

Jadi pertanyaan sebenarnya bukan hanya apakah akan mengotomatisasi. Melainkan apakah akan mendigitalkan proses sesuai kondisi sekarang, atau membangunnya ulang terlebih dulu.

Tim sering melewatkan jeda itu karena proses saat ini sudah berjalan bertahun-tahun, jadi terasa teruji. Padahal usia menyembunyikan kontrol yang berguna dan kebiasaan usang. Proses yang berlangsung lama bisa berisi satu langkah yang melindungi kualitas dan langkah lain yang ada hanya karena sistem lama tidak fleksibel.

Pekerjaan manual rumit karena alasan itu persis. Satu langkah bisa mengandung nilai sekaligus pemborosan. Seorang manajer yang meninjau setiap pengembalian dana pelanggan mungkin menemukan kasus tidak biasa, yang berguna. Tetapi jika manajer yang sama juga menyalin catatan yang sama ke sistem kedua, bagian itu tidak memberi nilai. Jika Anda mengubah seluruh langkah itu menjadi perangkat lunak apa adanya, Anda mempertahankan bagian baik dan bagian buruk bersama-sama.

Waktu juga penting. Sebelum suatu alat dibuat, mengubah proses sebagian besar masih berupa percakapan. Setelah alat dibangun, perubahan mempengaruhi formulir, aturan, izin, laporan, pelatihan, dan kebiasaan harian. Perbaikan kecil pun bisa menjadi pengujian, rapat, dan pengerjaan ulang yang mahal.

Lebih cepat tidak selalu lebih baik. Kecepatan membantu hanya jika proses sudah membuat keputusan yang tepat. Jika aturan persetujuan yang buruk diotomatisasi, Anda hanya mendapatkan persetujuan buruk lebih cepat. Tim mungkin merasa lebih efisien sementara kesalahan, penundaan, dan frustrasi pelanggan terus meningkat di bawah permukaan.

Hal ini semakin penting sekarang ketika perangkat lunak bisa dibangun cepat. Alat yang cepat berguna, tetapi juga meningkatkan biaya melewatkan langkah berpikir. Pembangunan cepat yang mengelilingi alur kerja berantakan tetaplah alur kerja berantakan, hanya dengan antarmuka yang lebih rapi.

Apa yang harus disimpan, disederhanakan, atau dihapus

Tidak setiap langkah manual adalah pemborosan. Beberapa langkah melindungi kualitas, menangkap risiko, atau membangun kepercayaan. Sebelum Anda mendigitalkan atau membangun ulang proses, pisahkan pekerjaan yang membutuhkan penilaian manusia dari pekerjaan yang ada hanya untuk menahan sistem yang lemah.

Sebuah aturan sederhana membantu: simpan langkah di mana seseorang menambahkan makna, bukan hanya gerakan. Jika seorang manajer meninjau pengembalian dana yang tidak biasa, itu mungkin layak disimpan karena konteks penting. Jika tiga orang menyalin detail pengembalian dana yang sama dari email ke spreadsheet lalu ke formulir, itu hanya informasi yang bergerak.

Sebagian besar langkah masuk ke salah satu dari empat kelompok:

• Simpan jika seseorang membuat keputusan nyata.
• Sederhanakan jika tujuannya penting tetapi pemeriksaannya terjadi terlalu sering.
• Hapus jika itu hanya menyalin, meneruskan, atau memformat ulang data.
• Pertanyakan dengan keras jika tidak ada yang ingat mengapa langkah itu ada.

Banyak tim membawa tugas ekstra karena alat mereka saat ini buruk. Orang mengejar persetujuan lewat chat, memperbarui dua pelacak, atau menyimpan file dengan nama khusus agar orang lain bisa menemukannya nanti. Itu bukan kebutuhan bisnis. Itu solusi sementara.

Jika Anda membangun setiap solusi sementara ke dalam sistem baru, Anda mengunci rasa sakit lama ke layar yang lebih rapi. Itu sebabnya beberapa proyek perangkat lunak terasa lambat dan membuat frustrasi pada hari pertama.

Kebiasaan lama adalah jebakan lain. Beberapa aturan dibuat untuk formulir kertas, kekhawatiran audit lama, atau manajer yang sudah pergi bertahun-tahun lalu. Tanda tangan mingguan, laporan ganda, atau cetakan wajib mungkin pernah masuk akal. Jika risikonya sudah hilang, aturannya juga harus hilang.

Bayangkan tim penjualan yang memasukkan detail prospek ke CRM, lalu mengirim email detail yang sama ke bagian keuangan, lalu menunggu persetujuan manual sebelum mengirim penawaran. Persetujuan itu mungkin masih diperlukan saat harga tidak biasa. Entri ganda dan email seharusnya hilang.

Jika Anda berencana membangun alur kerja di alat seperti Koder.ai, langkah penyortiran ini menghemat waktu. Perangkat lunak harus mendukung bagian proses yang bernilai, bukan mempertahankan bagian yang hanya ditoleransi orang.

Kerangka sederhana untuk memutuskan

Jangan mulai dari bagan alur saat ini. Mulai dari tujuan setiap langkah. Sebuah proses bisa memiliki banyak langkah tetapi tetap melakukan sedikit. Langkah lain mungkin terasa lambat, tetapi bisa jadi itu satu hal yang mencegah kesalahan mahal.

Cara praktis menilai tiap langkah adalah dengan mengajukan empat pertanyaan:

• Hasil apa yang dilindungi oleh langkah ini?
• Siapa yang menggunakan keluaran ini, dan apa yang mereka lakukan dengan itu?
• Seberapa sering langkah ini mengubah keputusan nyata?
• Apakah ini mengurangi risiko, atau lebih banyak menciptakan waktu tunggu?

Jawaban biasanya mengarah ke salah satu dari empat pilihan. Simpan langkah jika jelas melindungi kualitas, uang, kepatuhan, atau kepercayaan pelanggan. Sederhanakan jika tujuannya valid tetapi metode saat ini canggung. Hapus jika tidak ada yang benar-benar menggunakan keluaran atau jika hampir tidak pernah mengubah apa yang terjadi selanjutnya. Bangun ulang jika tujuannya sah tetapi keseluruhan urutan dibangun di sekitar batas lama.

Tanda peringatan kuat adalah penundaan tanpa perlindungan. Jika sebuah langkah menambah satu hari menunggu tetapi tidak menangkap kesalahan, mencegah penipuan, atau memperbaiki hasil, itu lemah. Itu bisa terasa penting karena sering disentuh orang, bukan karena mengubah apa pun.

Ambil contoh pengembalian dana pelanggan. Jika setiap pengembalian kecil perlu persetujuan manajer dan manajer menyetujui 99 dari 100 tanpa perubahan, langkah itu tidak memperbaiki keputusan. Itu lebih menambah waktu antrean. Aturan yang lebih baik mungkin persetujuan otomatis di bawah jumlah tertentu, dengan peninjauan hanya untuk kasus tidak biasa.

Inilah inti digitalisasi proses. Jangan bertanya, "Bisakah perangkat lunak menyalin ini?" Tanyakan, "Haruskah ini tetap ada setelah perangkat lunak membuat perubahan menjadi lebih mudah?" Pergeseran itu membantu Anda menghindari mengunci kebiasaan lama ke dalam sistem baru.

Cara meninjau proses langkah demi langkah

Mulai dengan proses nyata, bukan versi kebijakan. Amati bagaimana pekerjaan berlangsung hari ini, siapa yang menyentuhnya, alat apa yang mereka gunakan, dan di mana orang berhenti, menunggu, atau memperbaiki kesalahan. Papan tulis, dokumen bersama, atau tabel sederhana sudah cukup.

Jaga peta tetap sederhana. Untuk setiap langkah, catat empat hal: apa yang memicunya, siapa yang melakukannya, input apa yang dibutuhkan, dan output apa yang dihasilkan. Jika dua orang mendeskripsikan langkah yang sama secara berbeda, itu biasanya berarti proses sudah menyimpang.

Lalu ajukan satu pertanyaan untuk setiap langkah: mengapa ini ada?

Sebagian besar jawaban masuk dalam tiga kelompok:

1. Nilai - membantu menghasilkan hasil yang benar-benar dibutuhkan pelanggan atau tim.
2. Kontrol - mengurangi risiko, memeriksa kualitas, atau menyimpan catatan.
3. Pemborosan - menambah penundaan, duplikasi, atau pekerjaan sibuk tanpa manfaat jelas.

Banyak langkah manual terasa penting hanya karena orang sudah terbiasa. Menyalin data dari satu spreadsheet ke spreadsheet lain bisa tampak seperti pekerjaan teliti, tetapi seringkali itu hanyalah solusi sementara untuk sistem yang kurang.

Setelah setiap langkah diberi label, uji apa yang terjadi jika Anda menggabungkannya, memendekkannya, atau menghapusnya. Jika tidak ada yang rusak, langkah itu kemungkinan tidak diperlukan. Jika langkah kontrol penting, lihat apakah bisa terjadi nanti, terjadi sekali saja alih-alih dua kali, atau dipicu hanya untuk pengecualian.

Juga membantu memutuskan apa yang harus tetap manual untuk sekarang. Tidak semua penilaian harus menjadi perangkat lunak sejak hari pertama. Jika sebuah langkah bergantung pada konteks, kepercayaan, atau kasus pinggiran yang jarang, biarkan manual sampai proses baru terbukti stabil.

Sebelum pembangunan dimulai, tuliskan alur baru dengan bahasa sederhana. Sertakan jalur utama, pengecualian, siapa yang menyetujui apa, dan apa yang dianggap selesai. Versi satu halaman seringkali cukup. Itu menjadi sumber kebenaran bagi semua orang.

Garis besar berbahasa sederhana semacam itu juga bekerja baik saat Anda menggunakan pembangun berbasis chat. Itu memberi alat sesuatu yang jelas untuk dibangun, alih-alih memaksanya mencerminkan proses yang berantakan.

Contoh realistis: pekerjaan persetujuan sebelum perangkat lunak

Tim penjualan menangani persetujuan pelanggan lewat email. Seorang perwakilan membuat kuotasi, mengirimkannya ke manajer, menunggu balasan, lalu meneruskan kuotasi yang sama ke bagian keuangan. Terkadang kuotasi juga dikirim ke direktur penjualan sebelum sampai ke pelanggan.

Di atas kertas, itu terlihat teliti. Dalam praktiknya, itu menciptakan penundaan, kekacauan kotak masuk, dan pemeriksaan berulang.

Bagian yang berguna adalah keuangan. Tinjauan itu menangkap kesalahan harga nyata, terutama saat diskon dimasukkan manual atau perwakilan menggunakan lembar harga lama. Keuangan juga menemukan kasus di mana syarat pembayaran tidak sesuai kebijakan perusahaan. Langkah itu melindungi margin dan mencegah koreksi memalukan nanti.

Masalahnya adalah loop persetujuan lainnya. Manajer dan direktur penjualan sering memeriksa bidang yang sama yang sudah diperiksa keuangan: tingkat diskon, total nilai, dan detail pelanggan dasar. Mereka jarang menambah keputusan yang berbeda. Sebagian besar waktu, mereka hanya membalas dengan "disetujui" setelah membaca angka yang sama.

Apa yang berubah

Daripada menyalin rantai email lama ke perangkat lunak, tim menggambar ulang alur di sekitar satu kontrol nyata:

• Kuotasi standar dalam aturan harga dikirim tanpa persetujuan ekstra.
• Kuotasi dengan diskon atau syarat pembayaran yang tidak biasa dikirim ke bagian keuangan.
• Keuangan menyetujui, membetulkan, atau mengembalikannya sekali.

Itu menjaga pemeriksaan yang penting dan menghapus loop yang hanya memperlambat.

Perangkat lunak harus mencerminkan alur yang lebih bersih itu, bukan kekacauan lama. Jika tim membangun ini dalam alat internal, formulir kuotasi bisa memvalidasi harga secara otomatis, menandai pengecualian, dan mengarahkan hanya kasus berisiko untuk ditinjau. Perwakilan melihat status di satu tempat alih-alih mencari utas email.

Itu adalah tes kunci: apakah sebuah langkah mengubah hasil, atau hanya mengulang pemeriksaan yang sudah dilakukan orang lain?

Dalam contoh ini, satu tinjauan manual tetap karena mencegah kesalahan mahal. Persetujuan lain dihapus karena tidak menambah penilaian baru. Pekerjaan proses yang baik mempertahankan kontrol, menghapus kebisingan, lalu membangun perangkat lunak di sekitar jalur yang lebih sederhana.

Kesalahan umum yang menyebabkan pengerjaan ulang mahal

Kesalahan paling mahal biasanya terjadi sebelum alat dipilih. Sebuah tim memetakan proses saat ini, melihat daftar panjang langkah, dan memutuskan menyalin semuanya ke perangkat lunak karena itulah cara orang bekerja sekarang. Namun kebiasaan bukanlah nilai. Jika sebuah langkah ada hanya karena formulir kertas hilang, atau karena seseorang pernah membuat kesalahan lima tahun lalu, memasukkannya ke sistem hanya membuat pemborosan lebih cepat.

Kesalahan sebaliknya sama berisikonya. Sebuah tim melihat penundaan dan menghapus persetujuan atau pemeriksaan tanpa menanyakan risiko apa yang dikendalikan oleh kontrol itu. Beberapa kontrol tidak perlu, tetapi beberapa melindungi uang, kepatuhan, data pelanggan, atau kualitas layanan. Ketika pengaman itu hilang, proses mungkin terlihat lebih bersih selama seminggu lalu menimbulkan masalah yang lebih besar.

Perangkap umum lain adalah mengotomatisasi pengecualian sebelum memperbaiki jalur utama. Kasus tidak biasa menyakitkan dan mudah diingat, jadi tim fokus pada mereka terlebih dulu. Hasilnya adalah alur kerja kompleks yang dibangun di sekitar kasus pinggiran sementara 80 persen pekerjaan rutin tetap lambat dan membingungkan. Rancang untuk kasus normal dulu. Lalu tambahkan penanganan sederhana untuk pengecualian yang benar-benar penting.

Tim juga bermasalah ketika satu pemangku kepentingan yang paling keras suaranya menjadi wakil seluruh proses. Manajer mungkin peduli tentang pelaporan, kepala keuangan peduli tentang aturan persetujuan, dan staf garis depan peduli tentang kecepatan. Jika hanya salah satu pandangan itu yang membentuk desain, perangkat lunak cocok untuk satu orang dan membuat frustrasi orang lain.

Percobaan singkat menangkap banyak masalah ini lebih awal, namun banyak tim melewatkannya karena ingin bergerak cepat. Bahkan uji sederhana dengan pengguna nyata sering mengungkap masalah seperti langkah yang berada di urutan salah, informasi yang hilang saat serah terima, persetujuan yang menimbulkan penundaan tapi tidak menambah proteksi, kasus langka yang sebenarnya tidak umum, dan layar yang hanya masuk akal bagi tim proyek.

Ini semakin penting di lingkungan pembangunan cepat. Koder.ai, misalnya, memungkinkan tim membuat aplikasi web, server, dan mobile melalui antarmuka berbasis chat. Kecepatan itu berguna, tetapi hanya jika alur kerja sudah ditantang dan dibersihkan.

Daftar periksa singkat sebelum Anda mendigitalkan

Sebelum memutuskan apakah akan mendigitalkan atau membangun ulang proses, berhenti sejenak dan lakukan satu tinjauan singkat. Sebuah proses bisa terasa penting karena memiliki banyak langkah, serah terima, dan persetujuan. Itu tidak berarti setiap bagian berguna.

Gunakan daftar periksa ini dengan orang yang melakukan pekerjaan setiap hari. Lalui satu kasus nyata dari awal sampai akhir, bukan versi ideal yang tertulis di file kebijakan.

• Dapatkah seseorang menjelaskan tujuan langkah ini dalam satu kalimat jelas?
• Apakah langkah ini benar-benar mengubah hasil, mengurangi risiko, atau meningkatkan kualitas?
• Jika langkah ini hilang besok, apakah proses masih berjalan?
• Jika langkah menambah waktu tunggu, perlindungan apa yang diciptakan oleh penundaan itu?
• Apakah versi yang lebih sederhana sudah diuji pada satu kasus kecil dan berisiko rendah?

Contoh kecil membuatnya nyata. Bayangkan tim di mana setiap pengembalian dana kecil pelanggan membutuhkan tanda tangan manajer. Jika hampir setiap pengembalian dana tetap disetujui, langkah itu mungkin hanya mendokumentasikan otoritas alih-alih memperbaiki keputusan. Dalam kasus itu, batas pengembalian dengan pemeriksaan acak mungkin melindungi bisnis sama baiknya dengan lebih sedikit penundaan.

Aturannya sederhana: simpan langkah yang mengubah hasil, sederhanakan yang melindungi kualitas, dan hapus yang hanya membuat pekerjaan terasa resmi. Jika sebuah langkah tidak bisa membenarkan waktunya, itu tidak boleh dikunci ke dalam perangkat lunak.

Cara mengubah proses baru menjadi perangkat lunak

Setelah Anda membersihkan proses, jangan lompat langsung ke layar, formulir, dan otomasi. Mulai dengan menulis proses sebagai seperangkat aturan jelas: apa yang memulai pekerjaan, siapa pemilik tiap langkah, informasi apa yang harus diteruskan, dan apa yang dianggap selesai.

Uji yang berguna adalah ini: bisakah rekan baru mengikuti alur tanpa berhenti bertanya? Jika tidak, perangkat lunak juga akan membingungkan.

Tulis jalur default dulu

Sebagian besar pekerjaan mengikuti rute dasar yang sama. Bangun rute itu terlebih dulu. Untuk setiap serah terima, definisikan:

• apa yang memicu langkah
• siapa yang bertanggung jawab
• informasi apa yang diperlukan
• kapan respons harus diberikan
• apa yang terjadi selanjutnya setelah disetujui, ditolak, atau tidak ada respons

Ini menjaga sistem fokus pada pekerjaan normal alih-alih kasus pinggiran.

Lalu tandai titik di mana penilaian manusia masih penting. Sebuah aturan bisa mengarahkan permintaan, mengirim pengingat, atau memeriksa apakah sebuah bidang kosong. Tetapi beberapa keputusan tetap butuh orang. Mungkin manajer meninjau pengeluaran tidak biasa, atau kepala dukungan memutuskan apakah permintaan pelanggan layak melanggar kebijakan. Nama-namakan momen itu jelas agar tidak terkubur dalam label samar seperti "tinjauan khusus."

Setelah itu, definisikan beberapa pengecualian yang layak ditangani sekarang. Jaga daftar singkat. Jika sesuatu terjadi sekali setiap beberapa bulan, biarkan manual dulu. Itu biasanya lebih baik daripada membangun logika ekstra yang tidak digunakan siapa pun.

Simpan catatan versi sejak awal. Catatan singkat tentang apa yang berubah, kapan, dan mengapa memudahkan pembaruan nanti. Itu juga membantu ketika tim bertanya mengapa sistem berperilaku seperti itu.

Jika Anda menggunakan platform seperti Koder.ai, catatan itu bisa berfungsi ganda sebagai spesifikasi berbahasa sederhana. Semakin jelas aturannya, semakin bersih build pertama.

Perlakukan versi pertama sebagai jalur umum yang dilakukan dengan baik. Jangan membangun berlebihan untuk kasus tidak biasa. Mulai dengan alur yang digunakan orang setiap hari, pertahankan penilaian manusia terlihat, dan tambahkan lebih banyak hanya ketika penggunaan nyata membuktikan perlu.

Langkah selanjutnya untuk rollout kecil dan aman

Mulai dari kecil. Pilih satu proses yang menyakitkan sehingga penting, tetapi cukup terkandung sehingga kesalahan tidak mengganggu seluruh bisnis.

Pilot yang baik biasanya memiliki pemilik jelas, kelompok pengguna kecil, dan banyak pekerjaan manual berulang. Persetujuan pengeluaran untuk satu departemen, serah terima prospek untuk satu tim penjualan, atau intake pelanggan untuk satu lini layanan adalah contoh yang baik.

Jika Anda masih mempertimbangkan apakah akan mendigitalkan atau membangun ulang, langkah teraman bukanlah peluncuran perusahaan-persekan. Uji versi yang dibersihkan dulu dengan kelompok sempit dan amati apa yang terjadi dalam kerja nyata.

Apa yang harus diuji dulu

Jalankan pilot singkat dengan beberapa pengguna nyata. Beri jangka waktu tetap, misalnya dua sampai empat minggu, agar semua tahu itu uji coba bukan versi final.

Fokus pada beberapa sinyal sederhana:

• waktu yang dihemat per tugas atau kasus
• kesalahan, pengerjaan ulang, atau serah terima yang terlewat
• umpan balik pengguna tentang kebingungan atau gesekan
• pengecualian yang masih perlu penanganan manual
• apakah manajer bisa melihat status lebih jelas

Jangan anggap versi pertama selesai. Umpan balik awal adalah tujuan utamanya. Jika orang terus bekerja mengakali sebuah langkah, itu biasanya berarti langkah itu tidak jelas, tidak perlu, atau kehilangan sesuatu yang penting.

Misalnya, sebuah tim memindahkan alur persetujuan berbasis kertas ke aplikasi sederhana. Pilot menunjukkan persetujuan lebih cepat, tetapi staf masih saling menelepon untuk menjelaskan detail yang hilang. Itu hasil berguna. Itu berarti alur kerja perlu formulir permintaan yang lebih baik sebelum rollout yang lebih luas.

Setelah proses bekerja untuk grup pilot, perluas bertahap. Tambah satu tim, lalu tim lain. Terus ukur beberapa angka yang sama agar bisa membandingkan hasil alih-alih mengandalkan opini.

Jika Anda ingin menguji ide cepat, Koder.ai bisa menjadi opsi praktis untuk mengubah alur kerja yang sudah dibersihkan menjadi aplikasi web atau mobile dari bahasa alami. Bagian pentingnya adalah urutan: perbaiki proses dulu, buktikan pada skala kecil, lalu baru perluas.