Gelombang pertama business process reengineering gagal karena alasan yang jujur: teknologi pada masa itu tidak mampu memberikan apa yang dijanjikan oleh teorinya. Pada tahun 1993 sebuah perusahaan bisa menggambar ulang sebuah proses di papan tulis, tetapi sistem yang menopangnya kaku, terikat pada pemrosesan batch, dan sulit diintegrasikan, sehingga rancangan ulang itu entah terhenti di batas mainframe atau merosot menjadi sekadar upaya penghematan biaya yang dibalut dengan bahasa transformasi. Gagasannya sehat, perkakasnya tidak, dan keduanya diingat sebagai satu kesatuan.

Kendala itu kini sebagian besar telah sirna. Antarmuka pemrograman aplikasi kini menjadi ekspektasi standar, bukan lagi proyek yang harus dibuat khusus. Event streaming, platform data cloud, dan mesin orkestrasi membuat penyusunan sebuah proses yang berjalan lintas beberapa sistem pencatatan menjadi layak tanpa perlu memindahkan data secara manual di antara sistem-sistem tersebut. Apa yang dahulu merupakan integrasi heroik kini menjadi rekayasa biasa. Akibatnya, pertanyaan reengineering, yang lama tertunda karena terlalu mahal untuk dijawab, kembali menjadi dapat dikerjakan, dan pertanyaan itu muncul kembali di sebagian besar organisasi dengan nama lain: perancangan ulang order-to-cash, onboarding pelanggan, ketahanan pasokan, percepatan penutupan buku keuangan.

Godaan untuk menunda pertanyaan reengineering dapat dipahami dan kini tidak lagi aman. Selama bertahun-tahun langkah rasionalnya adalah menunggu, karena biaya integrasi dari rancangan ulang yang serius mana pun melebihi manfaatnya, dan perusahaan menumpuk solusi tambal sulam dengan keyakinan penuh bahwa semuanya akan teratasi pada peningkatan sistem berikutnya. Kenyataannya jarang demikian. Setiap peningkatan mempertahankan bentuk proses lama karena memindahkan bentuk tersebut lebih murah daripada mempertanyakannya, dan rancangan yang tidak disengaja itu mengeras menjadi tampak permanen. Yang berubah adalah bahwa para pesaing yang berani mengajukan pertanyaan itu kini dapat bertindak berdasarkan jawabannya, dan sebuah proses yang memakan waktu dua kali lebih lama atau berbiaya dua kali lipat tidak lagi tersembunyi hanya karena semua orang sama lambatnya.

Ada alasan kedua mengapa pertanyaan ini penting saat ini. Tiga dekade adopsi perangkat lunak enterprise telah meninggalkan sebagian besar perusahaan besar dengan CRM yang memodelkan pelanggan, ERP yang memodelkan transaksi dan keuangan, serta rangkaian rantai pasok yang memodelkan material dan kapasitas, masing-masing dikonfigurasi oleh fungsi yang berbeda pada waktu yang berbeda dengan logika yang berbeda. Proses yang benar-benar menciptakan nilai, menerima pesanan dan memenuhinya, memperoleh pelanggan dan melayaninya, merencanakan pasokan terhadap permintaan yang sesungguhnya, berjalan lurus melintasi ketiganya. Organisasi disusun berdasarkan fungsi; pekerjaan disusun berdasarkan aliran; dan celah di antara keduanya adalah tempat berkumpulnya biaya, keterlambatan, dan kesalahan. Reengineering adalah disiplin untuk menutup celah itu secara sengaja alih-alih menutupinya dengan spreadsheet dan niat baik.

Wawasan pendiri reengineering, dan yang hingga kini paling banyak memberi hasil, adalah bahwa sebuah bisnis lebih jujur digambarkan melalui proses-prosesnya ketimbang melalui bagan organisasinya. Perusahaan yang berpusat pada fungsi mengoptimalkan setiap departemen terhadap targetnya sendiri: penjualan memaksimalkan pesanan, operasi meminimalkan biaya per unit, keuangan menjaga modal kerja. Masing-masing rasional secara lokal dan jumlahnya sering kali buruk secara keseluruhan, karena serah terima antarfungsi, tempat pelanggan sebenarnya menunggu, tidak menjadi milik siapa pun. Perusahaan yang berpusat pada proses membalik hal ini. Ia menamai aliran ujung-ke-ujung yang penting, memberi setiap aliran seorang pemilik dengan wewenang nyata melintasi batas fungsi, dan mengukur aliran itu secara utuh: waktu tempuh, first-pass yield, biaya untuk melayani, konversi kas.

Dari sini muncul sebuah pertanyaan awal yang berat, yang kami tegaskan harus dijawab sebelum rancangan ulang apa pun dimulai: reengineering, atau perbaikan bertahap? Keduanya tidak dapat dipertukarkan, dan mengacaukannya mahal ke kedua arah. Perbaikan bertahap adalah pilihan yang tepat ketika sebuah proses pada dasarnya sehat dan hanya terselubung pemborosan; di sini perkakas lean dan continuous improvement memberi hasil dengan cepat dan aman. Reengineering hanya dibenarkan ketika proses tersebut mengandung asumsi yang tidak lagi berlaku, ketika urutan langkahnya ada karena suatu kendala yang telah lama menghilang, atau ketika hasil yang diinginkan tidak dapat dicapai dengan penyetelan apa pun terhadap rancangan yang ada. Uji yang kami terapkan bersifat lugas. Jika Anda tidak mungkin sampai pada proses ini dengan merancang dari lembar kosong demi hasil yang diinginkan hari ini, ia adalah kandidat untuk dirancang ulang. Jika Anda mungkin sampai ke sana, ia adalah kandidat untuk diperbaiki.

Prinsip ketiga adalah bahwa sebuah proses yang membentang di CRM, SCM, dan ERP tidak dapat dirancang ulang hanya di salah satunya. Master pelanggan, master produk, logika penetapan harga, dan status pesanan adalah fakta bersama yang berdiam, secara berlebihan dan sering kali tidak konsisten, di ketiga sistem. Rancangan ulang yang sungguh-sungguh harus memutuskan di mana setiap fakta ditulis, bagaimana ia menyebar, dan sistem mana yang dipercaya ketika terjadi perbedaan. Inilah sebabnya kami memperlakukan data dan integrasi bukan sebagai perkara implementasi di hilir melainkan sebagai substansi rancangan itu sendiri. Model proses dan model data adalah dua sudut pandang atas hal yang sama, dan upaya reengineering yang menghasilkan diagram proses yang indah namun membiarkan kepemilikan data tak terselesaikan sebenarnya belum melakukan reengineering apa pun.

Prinsip keempat menopang ketiga prinsip lainnya: proses, sistem, dan organisasi bukanlah tiga hal yang harus diselaraskan melainkan satu hal yang dilihat dari tiga sudut. Ketika ketiganya diperlakukan sebagai alur kerja terpisah dengan tata kelola terpisah, masing-masing mengoptimalkan penyelesaiannya sendiri, dan ketiganya bertemu saat go-live dalam kontradiksi satu sama lain. Sistem memaksakan sebuah aliran yang organisasinya tidak berkapasitas untuk menjalankannya terhadap data yang oleh proses diasumsikan sudah bersih. Merancang ketiganya sebagai satu keputusan memang lebih menuntut secara intelektual dan jauh lebih murah dalam praktik, karena kontradiksinya ditemukan di atas kertas alih-alih di produksi.

Bidang ini terus bergerak, dan tidak selalu ke arah yang diiklankan para vendor. Beberapa pola layak disebutkan secara lugas karena mengubah cara sebuah rancangan ulang seharusnya didekati.

Komposabilitas alih-alih monolit. Asumsi bahwa satu rangkaian ERP tunggal harus memiliki sebagian besar proses mulai memberi jalan pada arsitektur sistem-sistem khusus yang dirangkai melalui integrasi. Lapisan keterlibatan pelanggan, mesin perencanaan, inti keuangan, dan sistem pemenuhan semakin terpisah, dipilih berdasarkan keunggulannya masing-masing dan disusun menjadi sebuah aliran. Ini membebaskan bagi perancangan proses, karena Anda tidak lagi terikat pada pandangan satu vendor tentang bagaimana order-to-cash seharusnya bekerja, tetapi hal ini memindahkan kesulitan ke lapisan integrasi dan tata kelola, yang kini menanggung keterpaduan yang dahulu disediakan oleh monolit.

Process mining sebagai bukti. Sepanjang sebagian besar sejarahnya, reengineering diawali dengan lokakarya tempat orang menggambarkan bagaimana mereka meyakini proses itu berjalan, yang secara konsisten merupakan fiksi. Process mining merekonstruksi proses yang sesungguhnya dari log peristiwa yang sudah dipancarkan oleh sistem, menampilkan setiap varian, putaran pengerjaan ulang, dan jalan pintas sebagaimana benar-benar terjadi. Kami kini menganggap memulai rancangan ulang tanpa bukti ini nyaris sebagai kelalaian. Bukti ini menggantikan opini dengan baseline terukur dan, kemudian, menyediakan instrumen yang memberi tahu Anda apakah rancangan ulang berperilaku sesuai maksud di produksi.

Cloud ERP dan realitas dua tingkat. Perpindahan ke cloud ERP sering dijual sebagai peluang untuk kembali ke proses standar dan meninggalkan kustomisasi bertahun-tahun, dan untuk pekerjaan yang benar-benar umum itu adalah nasihat yang sehat. Namun langkah yang sama sering mengeras menjadi lanskap dua tingkat, sebuah inti yang terstandardisasi yang dikelilingi sistem-sistem khusus yang menopang keunikan sesungguhnya sebuah perusahaan. Karena itu pertanyaan rancangannya bukanlah apakah harus mengustomisasi, melainkan di mana keunikan itu secara sah berdiam, menjaga inti tetap dekat dengan standar sembari membiarkan bagian tepi berbeda, serta mengintegrasikan keduanya secara sengaja alih-alih secara kebetulan.

Otomatisasi bergeser dari tugas ke proses. Generasi pertama otomatisasi, khususnya robotic process automation, sebagian besar meniru manusia yang mengeklik layar, yang justru mengukuhkan proses yang ada alih-alih merancangnya ulang. Pola yang lebih bermanfaat kini adalah mengotomatiskan aliran yang telah dirancang ulang pada tingkat proses, menggunakan orkestrasi dan integrasi native, serta menyisakan otomatisasi tingkat layar untuk kasus tepi sejati yang tidak memiliki antarmuka. Mengotomatiskan proses yang buruk hanya membuat Anda menjalankannya lebih cepat.

Sebuah proses yang direkayasa ulang hanya sebaik arsitektur yang menopangnya. Beberapa prinsip rancangan membedakan rancangan ulang yang bertahan dari yang diam-diam kembali ke keadaan semula.

Satu sumber kebenaran per fakta, bukan per sistem. Naluri untuk menyatakan satu sistem sebagai master atas segalanya sama kelirunya dengan tidak memiliki master sama sekali. Disiplinnya lebih halus: untuk setiap entitas dan atribut yang penting, tetapkan tepat satu sistem yang menuliskannya, dan biarkan sistem lain berlangganan. CRM dapat memiliki relasi pelanggan sementara ERP memiliki akun legal dan posisi kredit; yang penting adalah kepemilikannya eksplisit, disepakati, dan ditegakkan, sehingga rekonsiliasi berhenti menjadi ritual bulanan.

Integrasi sebagai kontrak, bukan sekadar koneksi. Antarmuka titik-ke-titik yang dibangun tergesa-gesa menjadi bagian paling rapuh dari lanskap sistem, karena masing-masing menyandikan asumsi yang tak seorang pun mencatatnya. Kami merancang integrasi sebagai kontrak berversi dengan peristiwa, payload, dan semantik yang terdefinisi, dimediasi melalui sebuah lapisan yang mampu menyerap perubahan di kedua sisi. Tujuannya adalah agar sebuah sistem dapat diganti di balik kontraknya tanpa setiap tetangga perlu mengetahuinya.

Rancang proses agar dapat diamati. Sebuah proses yang tidak dapat diukur saat berjalan tidak dapat dikelola, dan sebagian besar memang tidak dapat. Kami membangun aliran yang dirancang ulang sedemikian rupa sehingga status, waktu, dan pengecualiannya dipancarkan sebagai peristiwa secara bawaan, memberi masukan bagi process mining yang sama yang menetapkan baseline. Observabilitas bukanlah instrumentasi yang ditambahkan belakangan; ia adalah properti yang dirancang sejak awal, dan itulah yang memungkinkan proses terus membaik setelah proyek berakhir.

Rancang agar dapat dibalik. Rancangan ulang yang hanya bisa maju adalah rancangan ulang yang akan ditentang, karena biaya kesalahannya bersifat bencana. Kami membangun migrasi sedemikian rupa sehingga setiap peningkatan dapat dijeda, dijalankan paralel dengan sistem lama, dan dibatalkan jika buktinya menuntut demikian. Ini bukan sikap penakut; inilah yang membuat keberanian menjadi terjangkau. Ketika sebuah perubahan dapat dibalik dengan murah, sebuah organisasi akan mencoba perubahan yang tidak akan pernah berani ia ambil di bawah skema semua-atau-tidak sama sekali, dan justru upaya-upaya itulah yang berakumulasi menjadi transformasi nyata.

Rancang untuk pengecualian, bukan untuk jalur ideal. Sebagian besar rancangan ulang digambar untuk transaksi yang berperilaku baik, sementara sebagian besar biaya justru terletak pada yang tidak: pengiriman parsial, faktur yang disengketakan, pelanggan yang tercatat dua kali dengan nama yang sedikit berbeda. Sebuah proses yang mengarahkan pengecualiannya ke sebuah spreadsheet dan seorang individu yang bersedia belum benar-benar dirancang; ia baru dirancang setengah dan sisanya diserahkan pada niat baik manusia. Kami memodelkan jalur pengecualian secara eksplisit, memutuskan mana yang cukup sering sehingga layak diberi jalur kelas satu melalui sistem dan mana yang benar-benar cukup langka sehingga dapat diserahkan pada pekerjaan manual yang cermat, serta menjadikan pembedaan itu sebuah pilihan yang disengaja alih-alih kebetulan dari apa pun yang kebetulan didukung oleh perangkat lunak. Ukuran sejati sebuah rancangan ulang adalah bagaimana ia berperilaku pada hari Selasa terburuknya, bukan pada hari terbaiknya.

Cara-cara program semacam ini gagal cukup konsisten untuk dikatalogkan, dan sebagian besar merupakan kegagalan penilaian, bukan teknologi.

Penggantian ERP secara big-bang. Kesalahan tunggal yang paling mahal adalah mengganti ERP dan merekayasa ulang proses dalam satu peralihan serentak di seluruh perusahaan. Teorinya adalah bahwa pemutusan bersih menghindari biaya menjalankan dua dunia; praktiknya adalah risiko berlipat ganda, karena setiap masalah muncul sekaligus tanpa cara untuk mengisolasi penyebabnya, dan bisnis kehilangan kemampuan untuk kembali ke keadaan semula. Kami lebih memilih rancangan ulang yang diberikan per proses dan per domain, dengan aliran baru dibuktikan pada cakupan yang terbatas sebelum diperluas. Migrasi bertahap memang lebih lambat namun jauh lebih mungkin untuk sampai.

Mengotomatiskan kekacauan yang ada. Sebuah program yang memetakan proses saat ini, mengotomatiskannya dengan setia, dan menyebut hasilnya sebagai transformasi telah menghabiskan banyak biaya untuk bergerak lebih cepat ke arah yang salah. Otomatisasi harus mengikuti rancangan ulang, jangan pernah menggantikannya.

Merekayasa ulang diagram, bukan organisasi. Rancangan ulang yang mengubah sistem dan proses namun membiarkan insentif, peran, dan garis pelaporan tetap utuh akan diam-diam dibatalkan oleh orang-orang yang dirugikannya. Jika proses kini bersifat lintas fungsi tetapi bonus tetap bersifat fungsional, target fungsional yang menang. Kepemilikan proses tanpa wewenang hanyalah hiasan.

Utang data yang ditunda. Tim rutin menunda pekerjaan master data dan kualitas data karena dianggap tidak menarik, dengan niat menanganinya kemudian. Kelak proses yang dirancang ulang, yang mengasumsikan data bersih dan konsisten, berhadapan dengan kenyataan sesungguhnya dan terhenti. Kualitas data bukanlah tugas pembersihan yang berdampingan dengan proyek; ia adalah prasyarat agar proses berfungsi sama sekali. Rancangan yang dipimpin konsultan tanpa para operator di ruangan memperparah hal ini: rancangan ulang yang digambar sepenuhnya oleh spesialis akan melewatkan pengetahuan tacit orang-orang yang menjalankan pekerjaan, alasan mengapa sebuah langkah yang tampak berlebihan sebenarnya menopang beban, pengecualian yang terjadi mingguan namun tidak pernah didokumentasikan. Ketika para operator itu pertama kali menjumpai proses baru saat pelatihan, mereka menemukan celah-celahnya, dan kepercayaan mereka, sekali hilang, mahal untuk dipulihkan.

Cakupan berdasarkan sistem alih-alih hasil. Program yang dipiagamkan sebagai proyek ERP atau proyek CRM mewarisi batas-batas perangkat lunak alih-alih batas-batas pekerjaan, dan aliran lintas sistem, yang justru merupakan tempat nilai berada, jatuh ke celah di antara alur-alur kerja. Piagam seharusnya menamai sebuah hasil dan sebuah aliran, lalu membiarkan sistem-sistem berada di dalamnya.

Kami memulai dari aliran dan hasil, bukan dari sistem. Sebelum mengusulkan perubahan apa pun, kami menetapkan apa yang seharusnya dicapai oleh proses ujung-ke-ujung dalam istilah yang akan dikenali bisnis, waktu tempuh, biaya untuk melayani, konversi kas, upaya pelanggan, dan kami mengukur keadaan saat ini terhadapnya menggunakan data peristiwa yang sudah dimiliki sistem alih-alih cerita yang orang sampaikan di lokakarya. Baseline terukur itu menyelesaikan perdebatan pertama, apakah proses layak untuk direkayasa ulang atau diperbaiki, berdasarkan bukti alih-alih antusiasme.

Di mana rancangan ulang dibenarkan, kami merancang proses, model data, dan integrasi secara bersama-sama, memperlakukannya sebagai tiga sudut pandang atas satu keputusan alih-alih tiga proyek berurutan. Kami menyelesaikan kepemilikan setiap fakta bersama lintas CRM, SCM, dan ERP secara eksplisit, mendefinisikan integrasi sebagai kontrak berversi, dan menjadikan orkestrasi aliran sebagai artefak yang dapat diperiksa alih-alih logika yang berserakan di seluruh konfigurasi. Proses yang dirancang ulang dibangun untuk memancarkan statusnya sendiri, sehingga dapat diukur di produksi terhadap baseline yang sama yang membenarkan keberadaannya.

Kami memberikan per domain dan per aliran, tidak pernah melalui peralihan big-bang. Sepotong terbatas dari proses yang dirancang ulang dibuktikan di produksi, pada transaksi nyata, sebelum diperluas, sehingga risiko tetap terisolasi dan bisnis mempertahankan kemampuan untuk kembali ke keadaan semula. Sepanjang itu, kami memperlakukan perubahan organisasi, kepemilikan, insentif, dan peran, sebagai bagian dari rekayasa alih-alih hal yang dipikirkan belakangan, karena sebuah proses yang organisasinya tidak tersusun untuk menjalankannya tidak akan bertahan. Tujuan kami adalah rancangan ulang yang terus membaik setelah kami pergi, karena instrumen untuk mengelolanya telah dibangun sejak awal.

Kami berterus terang soal tempo. Sebuah rancangan ulang yang membentang di tiga sistem pencatatan tidak dapat secara jujur diselesaikan dalam satu kuartal, dan setiap proposal yang menjanjikannya sedang menjual sebuah peralihan alih-alih sebuah rancangan ulang. Kami mengurutkan pekerjaan sedemikian rupa sehingga setiap domain menghasilkan perbaikan yang terukur dengan sendirinya, yang memperoleh kepercayaan dan perhatian yang dibutuhkan untuk domain berikutnya, alih-alih meminta bisnis menahan napas sepanjang program bertahun-tahun demi satu imbalan yang jauh. Pengurutan itu juga mendisiplinkan rancangan itu sendiri: sebuah aliran yang diwajibkan membuktikan nilainya pada sepotong terbatas tidak dapat bersembunyi di balik janji bahwa segalanya akan berpadu pada akhirnya. Jika sepotong gagal memperbaiki hasil yang menjadi mandatnya, kami jauh lebih suka menemukannya pada satu domain daripada pada ketiganya sekaligus.

Yang membedakan pekerjaan kami dalam process reengineering adalah bahwa kami menolak memperlakukan CRM, rantai pasok, dan ERP sebagai wilayah terpisah dengan rancangan ulang terpisah. Kami memegang aliran ujung-ke-ujung, data yang mengalir melaluinya, dan organisasi yang mengoperasikannya dalam satu pandangan tunggal, dan kami menyelesaikan pertanyaan-pertanyaan sulit tentang kepemilikan dan integrasi sebagai keputusan rancangan alih-alih menundanya ke tahap implementasi. Itu adalah percakapan yang lebih sulit untuk dimulai dan hasil yang jauh lebih tahan lama untuk diselesaikan.

Ada pula konsekuensi praktis yang mengubah apa yang boleh diasumsikan oleh pekerjaan ini. Ketika sebuah penugasan menuntut kapabilitas yang belum ada, ia tidak perlu menunggu siklus pengadaan atau peta jalan sebuah vendor. enterprise platform dibangun untuk mengakomodasi hampir semua fitur dengan cepat, melalui agentic engineering: apa yang dibutuhkan dijelaskan dalam bahasa yang lugas dan dihasilkan dengan cepat, tetapi selalu dalam prinsip arsitektur yang kokoh dan di bawah jaminan mutu yang ketat, sehingga kecepatan tidak pernah mengorbankan keterpaduan, keamanan, atau kendali. Efeknya bersifat strategis, bukan sekadar praktis. Ia menggeser garis make-or-buy, menjaga opsionalitas tetap murah, dan membiarkan arsitektur mengikuti strategi alih-alih strategi yang menyesuaikan diri dengan apa pun yang kebetulan tersedia di rak.

Imbalan dari disiplin ini adalah serangkaian proses inti yang melakukan apa yang benar-benar dibutuhkan bisnis, diukur terhadap hasil yang menjadi perhatiannya, ditopang oleh arsitektur yang dapat berubah tanpa rusak, dan dijalankan oleh organisasi yang tersusun untuk menjalankannya. Itulah yang sejak dulu dimaksudkan untuk diberikan oleh reengineering, dan dengan perkakas masa kini akhirnya hal itu benar-benar dapat terwujud.