Cloud migration selesai. Tools baru sudah dibeli. Approval sudah tidak pakai kertas.
Dan approval yang dulu lima hari, sekarang tetap lima hari.
Yang berubah medianya, bukan prosesnya. Form kertas jadi form digital. Email jadi notifikasi aplikasi. Spreadsheet jadi dashboard. Semuanya terlihat lebih modern. Angkanya tidak bergerak.
Pola ini bukan kasus langka. Dalam laporan Flipping the Odds of Digital Transformation Success (2020), BCG memeriksa 70 transformasi digital dan menemukan hanya 30% yang benar-benar mencapai sasaran. Sebanyak 44% menghasilkan sebagian nilai tetapi meleset dari target, dan 26% hampir tidak menghasilkan apa-apa.
Angka 44% itu yang paling menarik. Bukan kegagalan total—organisasi-organisasi ini berhasil membangun sistemnya. Yang tidak mereka dapatkan adalah perubahan performa yang dijanjikan.
Salah satu penyebabnya sederhana: proses diotomatisasi sebelum dipahami.
Otomatisasi Mempercepat Proses, Bukan Memperbaikinya
Ada asumsi yang jarang diperiksa: pekerjaan manual adalah masalah, dan otomatisasi proses bisnis adalah jawabannya.
Otomatisasi melakukan satu hal dengan sangat baik—menjalankan proses yang sama, lebih cepat, lebih konsisten, tanpa lelah. Satu hal yang tidak dilakukannya: menilai apakah proses itu masih masuk akal.
Bayangkan approval dengan tujuh tahap. Tiga tahap warisan kebijakan yang sudah dicabut dua tahun lalu. Dua tahap memeriksa hal yang sama dari sudut berbeda. Satu tahap menunggu satu orang yang juga memimpin tiga proyek lain.
Otomatisasi proses itu apa adanya, dan hasilnya: tujuh tahap tetap tujuh tahap. Bottleneck tetap di orang yang sama. Bedanya, sekarang bottleneck itu punya SLA, dashboard, dan notifikasi otomatis.
Ada efek kedua yang lebih mahal. Proses manual bisa diubah lewat satu memo dan rapat tiga puluh menit. Proses yang sudah tertanam di workflow engine, terhubung ke tiga sistem, dan dipakai empat ratus orang membutuhkan change request, regression testing, dan jendela rilis.
Masalahnya tidak hilang. Masalahnya jadi lebih mahal untuk dibongkar.
Tapi “Perbaiki Dulu” Bukan Aturan Mutlak
Nasihat improve before automate sering disampaikan seolah selalu benar. Dalam praktik, ada empat situasi di mana mengotomatisasi proses yang belum sempurna justru keputusan yang tepat.
1. Anda belum punya data untuk memperbaiki apa pun
Ini kasus yang paling sering, dan paling sering diabaikan. Process mining—cara paling objektif untuk melihat bottleneck, variasi, dan rework—membutuhkan event log: catatan yang berisi minimal case ID, nama aktivitas, dan timestamp, yang diambil dari sistem informasi.
Proses yang masih berjalan lewat email, grup WhatsApp, dan spreadsheet bersama tidak meninggalkan jejak semacam itu. Anda bisa mewawancarai sepuluh orang dan mendapat sepuluh versi proses yang berbeda, semuanya diucapkan dengan yakin.
Dalam kondisi ini, mendigitalkan alur apa adanya adalah cara memasang alat ukur. Perbaikannya menyusul di iterasi berikutnya—kali ini dengan data, bukan dengan ingatan orang.
2. Prosesnya stabil dan bervolume tinggi
Kalau sebuah proses berjalan delapan ribu kali sebulan dan alurnya tidak berubah dua tahun terakhir, penghematan dari otomatisasi bisa langsung terasa meski alurnya belum optimal. Redesign tetap perlu. Tapi tidak harus mendahului.
3. Ada tenggat kepatuhan atau audit
Kadang yang dibutuhkan regulator adalah jejak yang bisa diverifikasi, bukan alur yang efisien. Digitalkan dulu untuk memenuhi kewajiban, rapikan setelahnya.
4. Redesign membutuhkan keputusan yang belum bisa diambil
Memangkas tiga tahap approval berarti mencabut kewenangan tiga orang. Kalau keputusan itu belum matang secara organisasi, menunggu sampai politiknya selesai sering berarti menunggu selamanya.
Menariknya, AWS Cloud Adoption Framework pun tidak menempatkan proses di urutan pertama. Value chain-nya berjalan dari transformasi teknologi ke proses, lalu ke organisasi, lalu ke produk. Teknologi yang membuka jalan bagi perubahan proses, bukan sebaliknya.
Jadi pertanyaannya bukan “proses atau teknologi duluan”. Pertanyaannya:
Apakah kita sudah tahu di mana masalahnya?
Kalau sudah, perbaiki dulu. Kalau belum, digitalkan secukupnya sampai bisa mengukur—lalu perbaiki.
Petakan Proses yang Berjalan, Bukan Proses yang Tertulis
Sebelum memilih workflow engine, automation platform, atau aplikasi baru, petakan bagaimana pekerjaan benar-benar berjalan. Bukan bagaimana SOP-nya berbunyi.
Jarak antara keduanya adalah tempat sebagian besar masalah bersembunyi. Dalam literatur business process management, keduanya dibedakan sebagai process as designed dan process as executed. Yang pertama ada di dokumen. Yang kedua yang menentukan berapa lama approval Anda.
Pendekatan ini sejalan dengan riset APQC tentang process understanding sebelum automation, yang menempatkan pemahaman proses sebagai titik awal, bukan pemilihan teknologi.
Delapan pertanyaan untuk sesi pemetaan pertama
Jawab per proses, bukan per departemen.
- Berapa lama satu siklus, dari permintaan masuk sampai selesai?
- Berapa kali pekerjaan berpindah tangan?
- Di titik mana pekerjaan menunggu, dan berapa lama?
- Berapa persen pekerjaan yang harus diulang?
- Data apa yang disalin manual dari satu sistem ke sistem lain?
- Sistem apa saja yang tersentuh dalam satu siklus?
- Siapa yang benar-benar memutuskan, dan siapa yang hanya diberi tahu?
- Di mana kesalahan paling sering muncul?
Satu aturan praktis yang membantu menafsirkan jawabannya: waktu tunggu hampir selalu jauh lebih besar daripada waktu kerja. Kalau satu siklus approval memakan lima hari, kemungkinan besar pekerjaan aktualnya hanya beberapa jam. Sisanya antrean.
Otomatisasi yang mempercepat pekerjaan aktual tanpa menyentuh antrean akan menghemat menit, bukan hari.
Ukur Outcome Bisnis, Bukan Kelengkapan Sistem
Kesalahan berikutnya adalah mengukur keberhasilan dengan indikator yang paling mudah dihitung, bukan yang paling berarti.
| Inisiatif | Yang sering diukur | Yang sebaiknya diukur | Contoh target |
|---|---|---|---|
| Approval manual → workflow digital | Jumlah proses yang sudah digital | Cycle time end-to-end | 5 hari → 8 jam |
| Data tersebar → integration layer | Jumlah API yang dibangun | Jumlah versi angka yang beredar untuk satu metrik | 3 → 1 |
| Reporting manual → dashboard | Jumlah dashboard | Jeda antara kejadian dan ketersediaan datanya | 7 hari → 1 hari |
| Pekerjaan berulang → automation | Jumlah proses terotomatisasi | Jam kerja yang dialihkan ke pekerjaan lain | 120 jam/bulan |
| Legacy → modernisasi aplikasi | Jumlah aplikasi yang dimigrasi | Lead time perubahan fitur | 6 minggu → 1 minggu |
Satu langkah yang paling sering dilewati: ambil baseline sebelum implementasi dimulai. Tanpa angka awal, tidak ada cara membuktikan perbaikan apa pun—dan tidak ada cara membantah klaim bahwa tidak terjadi perbaikan.
Urutan Keputusan yang Sebaiknya Diikuti
Setelah proses dan metrik jelas, barulah arsitektur dibicarakan.
Proses → Outcome Bisnis → Arsitektur → Teknologi → Implementasi
Urutan ini menentukan pertanyaan apa yang diajukan di setiap tahap, dan siapa yang harus ada di ruangan:
- Proses — di mana waktu dan kualitas hilang?
- Outcome — angka apa yang harus berubah, dari berapa ke berapa?
- Arsitektur — struktur apa yang bisa menghasilkan perubahan itu dan tetap bisa dikembangkan?
- Teknologi — produk atau platform mana yang mengisi struktur itu?
- Implementasi — bagaimana urutan rilisnya agar nilai muncul lebih awal?
Dengan urutan ini, cloud migration berhenti menjadi proyek memindahkan server. System integration berhenti menjadi pekerjaan menyambungkan API. Semuanya kembali ke satu pertanyaan yang sama: perubahan performa proses apa yang ingin dicapai?
Yang Dibeli Perusahaan Bukan Teknologinya
Perusahaan tidak membeli cloud. Tidak membeli API. Tidak membeli dashboard.
Yang dibutuhkan hasilnya. Approval yang lebih cepat. Angka yang konsisten di semua rapat. Reporting yang aktual. Pekerjaan repetitif yang berkurang. Keputusan yang bisa diambil dengan data yang relevan.
Sistem baru memang terlihat lebih modern. Tapi transformasi yang berhasil terlihat dari angka yang bergerak: cycle time turun, handoff berkurang, rework menurun, data lebih konsisten.
Karena itu, sebelum membeli tools berikutnya, ada satu pertanyaan yang layak diajukan lebih dulu:
Proses apa yang angkanya ingin Anda ubah, dan dari berapa ke berapa?
Kalau pertanyaan itu belum bisa dijawab, masalahnya belum ada di pilihan teknologi.
Sagara Xinix sebagai IT Solution POWERHOUSE, siap berdiskusi untuk informasi lebih lanjut pada hello@sagara.com. Kami menawarkan sesi Process & Cycle Time Assessment. Setengah hari, satu proses, keluaran berupa peta alur aktual dan baseline metrik. Konkret, berbatas, dan langsung menjawab pertanyaan yang anda ajukan.
Pertanyaan yang Sering Diajukan
Apa itu otomatisasi proses bisnis?
Otomatisasi proses bisnis adalah penggunaan teknologi untuk menjalankan alur kerja yang sebelumnya dikerjakan manual—approval, entri data, pemindahan dokumen antar sistem, dan sejenisnya. Tujuannya mengurangi pekerjaan repetitif, mempercepat siklus, dan membuat hasilnya lebih konsisten.
Apakah proses harus diperbaiki dulu sebelum diotomatisasi?
Dalam banyak kasus, ya. Mengotomatisasi proses yang punya bottleneck, langkah tidak perlu, atau kualitas data yang buruk hanya membuat masalah itu berjalan lebih cepat—dan menanamkannya ke dalam konfigurasi sistem yang lebih mahal untuk diubah.
Kapan sebaiknya langsung mengotomatisasi tanpa memperbaiki proses lebih dulu?
Ketika Anda belum punya data untuk tahu di mana masalahnya, ketika prosesnya stabil dan bervolume sangat tinggi, ketika ada tenggat kepatuhan, atau ketika perbaikan menuntut keputusan organisasi yang belum bisa diambil. Dalam kasus pertama, digitalisasi justru berfungsi sebagai alat ukur.
Bagaimana mengukur keberhasilan otomatisasi proses bisnis?
Gunakan metrik outcome, bukan metrik kelengkapan sistem: cycle time, jumlah handoff, tingkat rework, kualitas data, kecepatan reporting, biaya per transaksi, dan jam kerja yang berhasil dialihkan ke pekerjaan bernilai lebih tinggi. Ambil baseline sebelum implementasi.
Apa bedanya otomatisasi proses bisnis dan digital transformation?
Otomatisasi proses bisnis adalah salah satu bagian dari digital transformation. Digital transformation cakupannya lebih luas dan mencakup perubahan proses, organisasi, data, produk, serta cara perusahaan menciptakan nilai.
Berapa lama waktu yang dibutuhkan untuk memetakan proses sebelum otomatisasi?
Untuk satu proses dengan cakupan jelas, sesi pemetaan awal biasanya cukup setengah hari sampai dua hari, tergantung jumlah pihak yang terlibat. Yang memakan waktu bukan pemetaannya, melainkan pengumpulan data pendukung dari sistem yang berbeda-beda.