Tidak semua inefisiensi bisnis muncul sebagai kerugian besar yang langsung terlihat dalam laporan keuangan. Sebagian justru hadir dalam bentuk aktivitas kecil yang terjadi setiap hari: employee memasukkan data yang sama ke dua aplikasi, menunggu approval, mencari dokumen, mengecek ulang informasi, berpindah dari ERP ke spreadsheet lalu ke email, melakukan reconciliation manual, atau menghubungi divisi lain untuk memastikan status sebuah transaksi. Masing-masing aktivitas mungkin hanya membutuhkan beberapa menit, tetapi ketika terjadi ratusan atau ribuan kali setiap bulan, akumulasinya dapat mengonsumsi kapasitas operasional yang signifikan.
Inilah yang dalam artikel ini Crocodic sebut sebagai Operational Friction Cost: biaya yang muncul ketika sebuah business process membutuhkan waktu, koordinasi, rework, waiting, atau aktivitas tambahan yang sebenarnya tidak berkontribusi langsung terhadap outcome yang ingin dicapai. Cost tersebut tidak selalu muncul sebagai satu line item di laporan keuangan. Ia tersebar dalam payroll, overtime, delayed transaction, additional headcount, longer cycle time, opportunity cost, hingga kebutuhan untuk mempertahankan pekerjaan administratif yang seharusnya dapat dikurangi.
Konsep bahwa aktivitas non-value-creating tetap mengonsumsi resource sudah lama menjadi bagian dari process improvement. Lean Enterprise Institute mengklasifikasikan waiting, unnecessary processing, motion, conveyance, inventory, overproduction, dan correction sebagai bentuk waste karena mengonsumsi resource tanpa menambah value bagi customer. Dalam konteks enterprise modern, bentuknya tidak selalu berupa employee yang menunggu material di production floor. Waiting dapat berarti invoice menunggu approval selama dua hari, customer request menunggu data dari system lain, atau management menunggu report karena proses consolidation masih manual. Lean Enterprise Institute
Karena itu, pertanyaan operational improvement tidak seharusnya hanya “berapa banyak proses yang masih manual?”. Pertanyaan yang lebih relevan adalah “berapa banyak waktu dan kapasitas perusahaan yang terus hilang karena friction di dalam proses tersebut, dan business impact apa yang dapat dipulihkan jika friction itu dikurangi?”
Operational Friction Bukan Hanya Proses Manual
Proses manual memang dapat menjadi sumber friction, tetapi digital process juga dapat tetap tidak efisien. Perusahaan bisa menggunakan ERP, CRM, workflow system, dashboard, dan berbagai SaaS tools sekaligus, namun employee masih harus berpindah antar-application, menyalin data, melakukan reconciliation, mencari status transaksi, atau meminta approval melalui channel di luar system.
Artinya, digitalized process tidak otomatis berarti optimized process.
Bayangkan proses procurement yang sudah menggunakan aplikasi. User membuat purchase request di system pertama, budget diverifikasi melalui system finance, procurement mengecek vendor di ERP, approval diberikan melalui workflow application, sementara komunikasi exception dilakukan melalui email atau chat. Secara teknis hampir semua step sudah digital, tetapi end-to-end process masih mempunyai banyak handoff dan context switching.
Frictions seperti ini mudah dianggap normal karena masing-masing step memang dapat diselesaikan. Problem baru terlihat ketika perusahaan mengukur total elapsed time dari request hingga selesai. Aktivitas yang benar-benar membutuhkan kerja mungkin hanya beberapa jam, sementara keseluruhan cycle time berlangsung beberapa hari karena sebagian besar waktu dihabiskan untuk waiting, handoff, searching, clarification, dan rework.
APQC mendefinisikan cycle time sebagai total waktu dari awal sampai akhir sebuah process dan secara eksplisit memasukkan waktu yang dihabiskan menunggu process dapat bergerak ke tahap berikutnya. Ini penting karena operational performance tidak cukup dinilai dari berapa lama seseorang mengerjakan satu task; perusahaan juga perlu melihat waktu ketika transaction hanya berada di queue. APQC
Dengan perspective tersebut, friction tidak hanya muncul karena pekerjaan dilakukan secara manual. Friction muncul ketika flow of work terputus, melambat, membutuhkan effort tambahan, atau harus melewati aktivitas yang tidak sebanding dengan value yang dihasilkan.
Crocodic Operational Friction Cost Framework
Dalam working framework Crocodic, Operational Friction Cost dapat dipetakan melalui chain:
Business Process → Friction Point → Frequency → Additional Effort / Delay → Downstream Impact → Root Cause → Technology or Process Intervention → Recovered Capacity → Business Outcome
Framework dimulai dari Business Process, bukan technology. Enterprise perlu menentukan aktivitas bisnis apa yang sedang dianalisis, misalnya order-to-cash, procurement, invoice processing, maintenance, customer onboarding, claims handling, reporting, atau approval.
Setelah itu, identifikasi Friction Point. Bentuknya dapat berupa waiting, duplicate input, manual reconciliation, searching, handoff, unnecessary approval, recurring exception, data correction, atau perpindahan antar-system. Friction kemudian harus dikaitkan dengan Frequency, karena lima menit tambahan yang terjadi sekali sebulan mempunyai materiality berbeda dibandingkan lima menit yang terjadi sepuluh ribu kali.
Berikutnya, perusahaan melihat Additional Effort / Delay. Tidak semuanya harus langsung dikonversi menjadi rupiah. Waktu kerja, queue time, repeat handling, number of touchpoints, atau jumlah employee yang terlibat sudah dapat menjadi baseline yang useful.
Barulah friction diterjemahkan menjadi Downstream Impact. Apakah menyebabkan invoice lebih lambat diterbitkan, customer menunggu lebih lama, inventory tidak cepat bergerak, manager terlambat mengambil keputusan, capacity team terpakai untuk administrative work, atau operation membutuhkan headcount tambahan ketika volume meningkat?
Setelah Root Cause ditemukan, perusahaan baru memilih Technology or Process Intervention. Intervention dapat berupa process simplification, integration, automation, data standardization, decision-rule redesign, software enhancement, atau bahkan menghapus step yang sebenarnya tidak diperlukan.
Framework ini penting karena Crocodic tidak melihat automation sebagai objective.
Objective-nya adalah menghilangkan friction yang cukup material untuk menghasilkan business outcome.
Friction Kecil Menjadi Mahal karena Volume dan Frekuensi
Salah satu alasan operational friction sulit mendapatkan perhatian management adalah setiap individual incident terlihat terlalu kecil untuk menjadi investment case.
Employee membutuhkan tiga menit untuk memindahkan data dari satu system ke system lain. Manager kehilangan sepuluh menit mencari document. Finance membutuhkan lima menit melakukan reconciliation. Sales harus mengirim satu message tambahan untuk mengecek status approval. Tidak ada satu kejadian yang tampak cukup besar untuk mendapatkan budget technology.
Namun operational cost perlu dilihat dalam skala.
Jika satu aktivitas tambahan memerlukan lima menit dan terjadi 2.000 kali sebulan, perusahaan kehilangan lebih dari 166 jam kerja setiap bulan hanya untuk satu friction point. Jika aktivitas tersebut membutuhkan dua role atau menimbulkan downstream waiting, actual impact menjadi lebih besar. Ini belum menghitung cost dari error, rework, delay, dan opportunity yang tidak dapat dikerjakan karena capacity sudah terserap.
Karena itu, salah satu working lens sederhana adalah:
Friction Load = Frequency × Additional Effort per Case
Kemudian expanded view-nya:
Operational Friction Cost = Direct Effort + Waiting Impact + Rework + Coordination Cost + Downstream Business Impact
Formula ini bukan accounting standard dan tidak dimaksudkan menghasilkan angka presisi secara otomatis. Fungsinya adalah membantu perusahaan melihat bahwa small friction × high frequency dapat mempunyai business relevance yang lebih besar dibandingkan satu pain point besar tetapi jarang terjadi.
Prinsip Lean memberikan dasar yang serupa. Lean Enterprise Institute membedakan value-creating work dari aktivitas incidental atau waste seperti waiting, correction, unnecessary motion, dan overprocessing. Ketika aktivitas semacam itu berulang dalam high-volume process, perusahaan membayar waktu tanpa memperoleh proportional customer value. Lean Enterprise Institute
Waiting Time Sering Lebih Besar daripada Processing Time
Salah satu bentuk friction yang paling sulit terlihat adalah waiting. Transaction tidak sedang dikerjakan, tetapi business outcome juga belum bergerak.
Purchase request menunggu approval. Invoice menunggu supporting document. Maintenance request menunggu assignment. Customer onboarding menunggu verification. Management report menunggu consolidation. Data migration menunggu clarification dari business owner.
Waiting berbeda dari processing time. Jika seseorang membutuhkan 20 menit untuk memeriksa request tetapi request tersebut menunggu dua hari sebelum diperiksa, improvement hanya pada processing time tidak banyak mengubah customer atau business experience.
Inilah alasan enterprise perlu mengukur elapsed cycle time, bukan hanya employee effort.
Lean Enterprise Institute menyebut waiting sebagai salah satu classic forms of waste karena waktu tersebut tidak menambahkan value pada process. Dalam service dan digital operation, konsep yang sama berlaku ketika information atau transaction berhenti karena queue, dependency, approval, atau unavailable input. Lean Enterprise Institute
Friction semacam ini juga menjelaskan mengapa menambah employee tidak selalu menyelesaikan problem. Jika bottleneck sebenarnya berada pada unclear decision rights, fragmented information, atau approval rule yang buruk, additional headcount hanya meningkatkan capacity di sekitar process yang masih mempunyai structural friction.
Karena itu, ketika cycle time terlalu lama, pertanyaan pertama sebaiknya bukan “apakah kita kekurangan orang?”, melainkan “berapa banyak dari total waktu process yang benar-benar digunakan untuk value-creating work dan berapa banyak yang hanya menunggu?”
Rework adalah Friction yang Membayar Pekerjaan yang Sama Lebih dari Sekali
Rework terjadi ketika transaction harus diperbaiki, dikembalikan, diinput ulang, direview ulang, atau diproses ulang karena hasil pertama tidak lengkap atau tidak benar.
Contohnya dapat berupa invoice yang kembali karena PO tidak sesuai, customer data yang perlu dikoreksi karena mandatory field tidak tervalidasi, procurement request yang bolak-balik antara user dan purchasing, atau monthly report yang harus direvisi karena masing-masing unit menggunakan definition berbeda.
Rework mahal karena satu business outcome membutuhkan lebih dari satu execution cycle.
Jika sebuah process mempunyai high rework rate, meningkatkan kecepatan pada individual task belum tentu memberikan improvement besar. Organization perlu menyelesaikan root cause yang menciptakan repeat work.
Lean Enterprise Institute memasukkan correction, rework, dan defect sebagai bentuk waste karena resource digunakan untuk memperbaiki output yang seharusnya dapat dihasilkan dengan benar sejak awal. APQC juga memasukkan error rate, percentage of work requiring rework, first-pass quality, dan percentage of transaction completed correctly the first time sebagai contoh process-efficiency measures. Lean Enterprise Institute
Karena itu, salah satu KPI yang berguna bukan hanya “berapa banyak transaction selesai?”, tetapi “berapa banyak transaction selesai tanpa harus kembali ke step sebelumnya?”
Semakin tinggi first-pass success, semakin kecil capacity yang habis untuk pekerjaan yang sama.
Handoff dan Context Switching Menciptakan Coordination Cost
Enterprise process biasanya melibatkan beberapa function. Procurement membutuhkan finance, sales membutuhkan operation, operation membutuhkan warehouse, dan management membutuhkan data dari berbagai business unit. Cross-functional process tidak selalu buruk; sebagian memang merupakan requirement organisasi. Friction muncul ketika setiap handoff membutuhkan manusia untuk mengumpulkan ulang context.
Misalnya request berpindah dari sales ke finance. Finance tidak mendapatkan seluruh informasi melalui system sehingga harus bertanya melalui chat. Setelah mendapat jawaban, finance mengirim request ke operation. Operation membutuhkan attachment lain dan kembali menghubungi sales. Seluruh stakeholder sedang bekerja, tetapi sebagian besar capacity digunakan untuk merekonstruksi information context yang terputus setiap kali process berpindah tangan.
Inilah salah satu area di mana Enterprise Application Integration dapat mempunyai business impact. Integration bukan bernilai hanya karena system berhasil bertukar data. Value muncul ketika integration mengurangi duplicate input, missing context, manual reconciliation, dan waiting antar-process.
Namun integration juga bukan otomatis jawaban. Jika process sendiri mempunyai terlalu banyak unnecessary handoff, mengintegrasikan seluruhnya hanya akan membuat inefficient process berjalan lebih cepat.
Karena itu, sequence yang lebih sehat adalah:
Understand the Process → Identify Friction → Simplify Where Possible → Integrate Where Necessary → Automate What Remains Valuable
Technology mengikuti business process, bukan sebaliknya.
Process Mining Dapat Menunjukkan Friction yang Tidak Terlihat di SOP
Salah satu kendala terbesar adalah organization sering hanya mengetahui process berdasarkan SOP atau workshop. Actual execution dapat jauh berbeda.
SOP menunjukkan lima steps. Event log menunjukkan delapan belas process variants. Sebagian transaction bolak-balik antar-step. Beberapa role mempunyai waiting time jauh lebih tinggi. Case tertentu membutuhkan banyak rework. Ada juga activity yang tidak tercantum pada process map tetapi selalu dilakukan employee agar transaction dapat selesai.
IBM menjelaskan process mining sebagai metode yang menggunakan event-log data dari system seperti ERP atau CRM untuk melihat bagaimana process benar-benar berjalan. Dari actual execution tersebut, organization dapat menemukan bottleneck, process variants, deviation, dan area yang mempunyai cycle time atau cost tinggi. IBM
Pendekatan ini relevan dengan artikel Crocodic Process Mining: Melihat Bottleneck yang Tidak Terlihat. Operational Friction Cost menggunakan insight tersebut satu langkah lebih jauh: setelah bottleneck ditemukan, enterprise perlu menentukan berapa banyak capacity atau business value yang hilang karena bottleneck tersebut dan apakah intervention layak menjadi investment priority.
Dengan demikian, process mining tidak berhenti sebagai visualization tool.
Ia dapat menjadi evidence layer untuk membuat business case improvement.
Jangan Mengotomasi Seluruh Friction tanpa Menemukan Root Cause
Ketika operational friction ditemukan, response paling mudah adalah automation. Jika employee melakukan input berulang, buat RPA. Jika approval lambat, buat workflow. Jika report manual, buat dashboard. Pendekatan tersebut dapat menghasilkan improvement, tetapi juga dapat mengotomasi process yang seharusnya diubah terlebih dahulu.
Contohnya, sebuah invoice harus melewati empat approval. Perusahaan kemudian membangun workflow agar approval lebih cepat. Namun setelah dianalisis, ternyata dua approval tidak mempunyai decision authority berbeda dan hampir selalu menyetujui request. Technology mempercepat unnecessary process tanpa menghilangkannya.
Hal yang sama dapat terjadi pada data reconciliation. Team dapat membuat automation untuk menyamakan dua master data, tetapi root cause sebenarnya adalah perusahaan mempertahankan dua source of truth.
Karena itu, artikel Crocodic Business Process Automation Enterprise: Mana yang Layak Diotomasi? penting sebagai context. Automation seharusnya diarahkan pada process yang mempunyai business value, cukup stabil, dan mempunyai root cause yang dipahami.
APQC juga menekankan bahwa process improvement sebaiknya dimulai dari process yang terdefinisi, baseline performance, dan ukuran seperti cycle time, quality, cost, serta productivity sebelum automation digunakan sebagai intervention. APQC
Prinsip Crocodic:
Jangan otomatisasi friction hanya karena friction tersebut repetitif. Hilangkan friction yang tidak perlu terlebih dahulu, baru otomatisasi pekerjaan yang memang tetap harus ada.
Ukur Recovered Capacity, Bukan Hanya Jam yang Dihemat
Salah satu kelemahan business case automation adalah terlalu cepat mengubah time saving menjadi financial saving.
Misalnya automation menghemat 1.000 jam per bulan. Angka tersebut kemudian langsung dikalikan dengan hourly cost employee dan dianggap sebagai saving. Padahal jika perusahaan tidak mengurangi headcount, angka tersebut bukan cash saving secara otomatis.
Namun bukan berarti manfaatnya tidak nyata.
Pertanyaan yang lebih akurat adalah apa yang terjadi terhadap capacity yang dipulihkan?
Recovered Capacity dapat digunakan untuk menangani transaction volume lebih besar tanpa menambah headcount, mempercepat response kepada customer, mengurangi overtime, memindahkan employee dari administrative work ke analytical work, mempercepat billing, meningkatkan service capacity, atau mengurangi backlog.
Itulah alasan Crocodic lebih menyukai chain:
Friction Reduction → Recovered Capacity → Operational Change → Business Outcome
dibandingkan:
Hours Saved = Profit
Business impact membutuhkan causal relationship yang lebih jelas.
Jika waktu finance yang sebelumnya digunakan reconciliation kemudian digunakan mempercepat closing process, outcome-nya adalah shorter closing cycle. Jika customer-service capacity meningkat tanpa penambahan FTE, outcome-nya adalah scalability. Jika maintenance team menerima work order lebih cepat, outcome dapat berupa shorter response time atau lower downtime.
Dengan cara tersebut, technology value menjadi lebih credible karena benefit tidak berhenti pada angka “jam yang dihemat”.
Prioritaskan Friction Berdasarkan Impact, Bukan Keluhan Terbesar
Tidak semua operational friction layak mendapatkan software project.
Employee dapat sangat terganggu oleh process yang merepotkan tetapi hanya terjadi beberapa kali per tahun. Sebaliknya, activity yang dianggap normal dan tidak banyak dikeluhkan dapat terjadi puluhan ribu kali serta mempunyai cumulative impact jauh lebih besar.
Karena itu, improvement backlog tidak seharusnya hanya mengikuti siapa stakeholder yang paling keras meminta feature.
Dalam working approach Crocodic, friction dapat diprioritaskan melalui lima dimensi: Frequency, Effort, Business Criticality, Downstream Impact, dan Intervention Feasibility. Friction yang sering terjadi, mengonsumsi effort besar, memengaruhi critical process, mempunyai downstream consequence tinggi, serta relatif feasible diperbaiki adalah kandidat yang lebih kuat.
Framework sederhananya:
Friction Point → Frequency → Effort / Delay → Business Impact → Root Cause → Intervention Feasibility → Priority
Di sinilah business-impact orientation berbeda dari feature-driven development. Feature-driven development bertanya “apa yang user ingin system lakukan?”. Business-impact orientation bertanya “friction apa yang paling menghambat outcome, dan intervention apa yang paling efektif menguranginya?”
Kadang jawabannya feature baru.
Kadang integration.
Kadang automation.
Kadang process redesign.
Dan kadang justru menghapus step atau application yang tidak lagi diperlukan.
Crocodic Perspective: Technology Harus Memulihkan Kapasitas Bisnis, Bukan Hanya Mengurangi Aktivitas Manual
Dalam perspective Crocodic, operational improvement tidak dinilai dari jumlah feature yang berhasil dibuat atau jumlah step yang berubah menjadi digital. Technology intervention dianggap bernilai ketika perubahan tersebut mengurangi friction dan menghasilkan measurable movement pada business process.
Framework lengkapnya adalah:
Business Process → Friction Point → Frequency → Additional Effort / Delay → Downstream Impact → Root Cause → Technology or Process Intervention → Recovered Capacity → Business Outcome
Framework ini membawa satu perubahan penting terhadap cara enterprise menyusun technology investment. Requirement tidak dimulai dari “butuh aplikasi approval”, “butuh dashboard”, atau “butuh AI Agent”. Requirement dimulai dari friction dan consequence-nya.
Jika problem utamanya fragmented system, Enterprise Application Integration mungkin menjadi intervention. Jika problemnya high-volume repetitive activity, Business Process Automation Enterprise dapat lebih relevan. Jika operating model sendiri terlalu fragmented, Digital Operating Model perlu dievaluasi. Dan jika enterprise membutuhkan capability yang tidak dapat dipenuhi secara efektif oleh existing platform, Custom Enterprise Software dapat menjadi salah satu intervention—tetapi tetap setelah business problem dan expected impact jelas.
Prinsipnya:
Feature adalah intervention. Friction reduction adalah perubahan operasional. Business impact adalah tujuan.
Kesimpulan
Operational inefficiency tidak selalu terlihat sebagai kerugian besar. Dalam banyak enterprise, cost justru tersebar dalam ribuan aktivitas kecil: waiting, duplicate input, searching, rework, reconciliation, handoff, follow-up, approval, dan perpindahan antar-system.
Masing-masing friction mungkin terlihat tidak material. Namun ketika dikalikan frequency, volume transaction, jumlah employee, serta downstream delay, accumulated impact dapat menjadi besar.
Karena itu, Crocodic menggunakan framework:
Business Process → Friction Point → Frequency → Additional Effort / Delay → Downstream Impact → Root Cause → Technology or Process Intervention → Recovered Capacity → Business Outcome
untuk membantu memindahkan diskusi dari “proses mana yang masih manual?” menjadi “friction mana yang paling banyak mengonsumsi kapasitas bisnis dan layak diperbaiki terlebih dahulu?”
Process mining dapat membantu menemukan bottleneck dan actual process variants. Cycle-time measurement menunjukkan berapa banyak waktu yang benar-benar digunakan dan berapa banyak yang hilang untuk waiting. Rework rate menunjukkan pekerjaan yang harus dilakukan lebih dari sekali. Integration dapat mengurangi fragmented information. Automation dapat menghilangkan repetitive work. Namun seluruh intervention tersebut baru relevan ketika dikaitkan dengan root cause dan business outcome yang ingin diubah.
Pada akhirnya, perusahaan tidak memperoleh value hanya karena sebuah task berhasil diotomasi.
Value muncul ketika technology membuat operation mampu memproses lebih banyak dengan resource yang sama, mempercepat cycle time, mengurangi rework, memperkecil backlog, meningkatkan service capacity, atau mengalihkan tenaga manusia dari aktivitas administratif menuju pekerjaan yang lebih bernilai.
Itulah inti dari Operational Friction Cost.
Bukan sekadar menghitung berapa menit yang hilang, tetapi memahami berapa banyak kapasitas bisnis yang dapat dipulihkan ketika friction yang terjadi setiap hari berhenti dianggap normal.
Discussion