Enterprise hampir tidak pernah menjalankan satu business process dengan cara yang benar-benar identik di seluruh organisasi. Cabang memiliki kebiasaan berbeda, business unit menggunakan approval flow sendiri, subsidiary mengikuti regulation yang berbeda, customer tertentu memiliki commercial treatment khusus, dan operational team sering mengembangkan workaround berdasarkan kebutuhan lokal. Sebagian variasi tersebut memang dibutuhkan agar bisnis dapat beroperasi secara efektif. Masalah muncul ketika setiap perbedaan diterjemahkan menjadi requirement software yang harus dipertahankan secara permanen.
Pada tahap awal, customization tambahan sering terlihat kecil. Cabang A membutuhkan satu approval tambahan. Cabang B menggunakan field berbeda. Business unit C mempunyai pricing rule sendiri. Subsidiary D membutuhkan workflow khusus. Tetapi ketika seluruh variasi tersebut terus ditambahkan ke application, enterprise dapat memiliki satu system secara nama namun sebenarnya menjalankan puluhan operating model di dalamnya. Setiap perubahan berikutnya menjadi semakin mahal karena engineering team harus mempertimbangkan lebih banyak condition, test scenario, permission, dependency, exception, dan integration.
Dalam artikel ini, Crocodic menggunakan Process Variance untuk menggambarkan perbedaan cara sebuah business process dijalankan antar-unit, lokasi, entity, product, atau kondisi tertentu. Process variance sendiri bukan selalu problem. Problem muncul ketika organization tidak dapat membedakan variation yang memang memberikan business value dengan variation yang hanya muncul karena historical habit, fragmented ownership, atau process yang belum pernah distandardisasi.
Microsoft dalam guidance mengenai standardisasi business process menjelaskan bahwa standardization bertujuan membangun metode dan praktik yang lebih seragam antar-department, function, geography, atau legal entity sehingga organization dapat mengurangi unnecessary variation, meningkatkan productivity, collaboration, quality, dan scalability. Microsoft sekaligus mengingatkan bahwa standardisasi yang terlalu rigid dapat mengurangi flexibility, sehingga organization tetap perlu menyeimbangkan consistency dengan legitimate business requirement.
Itulah inti persoalannya. Enterprise tidak perlu menghapus seluruh variation. Enterprise perlu mengetahui variation mana yang harus dipertahankan dan variation mana yang justru sedang mengubah technology menjadi penampung complexity organisasi.
Tidak Semua Perbedaan Proses Layak Disebut Business Requirement
Ketika software project memasuki requirement gathering, team sering mendengar kalimat seperti “di divisi kami caranya berbeda”, “cabang ini punya alur sendiri”, atau “selama ini kami memang mengerjakannya seperti ini”. Pernyataan tersebut penting untuk dipahami, tetapi belum cukup untuk menjadi justification bagi customization.
Cara kerja yang berbeda dapat muncul karena banyak alasan. Sebagian memang diwajibkan regulation, contractual obligation, atau market condition. Sebagian muncul karena business strategy. Namun sebagian lain hanya terjadi karena unit tersebut menggunakan spreadsheet yang berbeda, manager sebelumnya membuat approval sendiri, atau process berkembang secara lokal tanpa pernah dievaluasi secara enterprise.
Jika setiap current practice otomatis diterjemahkan menjadi requirement, digital transformation berisiko mendigitalisasi fragmentation yang sudah ada.
Software memang menjadi lebih terintegrasi secara teknis, tetapi operational model di bawahnya tetap terpecah. Bahkan fragmentation tersebut dapat menjadi lebih sulit diubah karena sekarang sudah ditanamkan ke business rule dan source code.
APQC dalam pembahasan mengenai appropriate process standardization menekankan bahwa standardization yang tepat bukan berarti menghapus seluruh context-driven variant. Standardisasi perlu memperhitungkan variasi yang memang diperlukan sekaligus membangun common process model dan governance yang cukup konsisten untuk menopang transformation. Ini memberikan principle penting bagi enterprise: variation perlu dibuktikan, bukan diasumsikan.
Pertanyaan requirement karena itu seharusnya bukan hanya “apakah cara kerja unit ini berbeda?”, tetapi “mengapa perbedaan tersebut harus tetap ada ketika kita mendesain future operating model?”
Process Variance Menjadi Mahal ketika Diterjemahkan ke Software Complexity
Perbedaan process yang kecil bagi business user dapat mempunyai consequence teknis yang jauh lebih besar. Tambahan satu approval step bukan hanya menambah satu button. Software mungkin perlu mengubah state machine, role permission, notification, audit trail, SLA, reporting logic, exception path, testing scenario, dan integration behavior.
Jika terdapat satu variation, complexity mungkin masih rendah. Tetapi jika lima business unit memiliki masing-masing workflow berbeda, interaction antar-condition mulai berkembang.
Semakin banyak variation, semakin sulit engineering team memahami impact sebuah perubahan.
Misalnya perusahaan mempunyai procurement platform yang digunakan sepuluh business unit. Tiga unit menggunakan dua tahap approval, empat unit menggunakan tiga tahap, dua unit membutuhkan budget verification tambahan, sedangkan satu unit mempunyai project-based approval. Ketika perusahaan ingin mengubah purchasing threshold, perubahan tersebut tidak lagi menjadi satu rule. Team harus memastikan seluruh process variant tetap bekerja.
Process variance dengan demikian menciptakan complexity multiplier.
Ini juga menjelaskan mengapa custom software tidak seharusnya dipahami sebagai kemampuan membuat semua hal berbeda. Custom Enterprise Software justru lebih valuable ketika digunakan untuk mengakomodasi business capability yang memang differentiating, bukan untuk mengabadikan seluruh historical variation di dalam organization.
Dalam perspective Crocodic, customization memiliki nilai jika melindungi business differentiation; customization menjadi liability ketika hanya melindungi operational inconsistency.
Crocodic Process Variance Framework
Untuk memisahkan variation yang bernilai dari variation yang tidak perlu, Crocodic menggunakan working framework:
Core Process → Local Variation → Variation Driver → Business Justification → Complexity Cost → Standardize / Configure / Customize
Framework dimulai dari Core Process, yaitu outcome dan high-level activity yang seharusnya konsisten secara enterprise. Setelah itu organization mengidentifikasi Local Variation dan mencari Variation Driver, bukan langsung membuat requirement.
Driver tersebut kemudian diuji terhadap Business Justification. Jika variation memang diperlukan, organization perlu menilai Complexity Cost sebelum menentukan apakah kebutuhan tersebut cukup ditangani melalui configuration atau benar-benar membutuhkan customization.
Hasil akhirnya bukan hanya dua pilihan “standard” atau “custom”. Ada tiga response yang lebih praktis. Standardize digunakan ketika variation tidak memiliki business justification yang cukup. Configure digunakan ketika variation valid tetapi masih dapat ditangani dalam predefined rule atau parameter. Customize digunakan ketika variation memang strategic atau mandatory dan tidak dapat dipenuhi secara efektif melalui common configuration.
Framework ini menggeser software discussion dari “apa yang user minta?” menjadi “variation apa yang layak menjadi bagian permanen dari operating model?”
Bedakan Mandatory, Strategic, dan Accidental Variation
Tidak semua process variance memiliki sifat yang sama. Dalam working classification Crocodic, variation dapat dibagi menjadi tiga kelompok: Mandatory Variation, Strategic Variation, dan Accidental Variation.
Mandatory Variation terjadi karena organization memang tidak memiliki pilihan untuk menyamakan process. Contohnya adalah perbedaan regulation antar-country, tax rule, reporting requirement, segregation of duties tertentu, atau contractual commitment kepada customer. Variation jenis ini merupakan constraint yang harus dihormati oleh operating model dan technology.
Strategic Variation berbeda. Perusahaan sengaja melakukan process dengan cara berbeda karena perbedaan tersebut mendukung competitive advantage atau customer proposition. Misalnya strategic account memiliki fulfillment model khusus, premium service mempunyai SLA berbeda, atau product line tertentu menggunakan pricing mechanism yang menjadi bagian penting dari business model. Variation seperti ini juga dapat layak dipertahankan.
Jenis ketiga adalah Accidental Variation. Perbedaan ini tidak memberikan regulatory atau strategic value. Ia muncul karena history, local preference, fragmented tool, individual manager, atau tidak adanya common process ownership. Cabang A menggunakan tiga approval karena sejak dulu seperti itu, sementara cabang B hanya dua. Divisi tertentu meminta report berbeda karena memiliki spreadsheet sendiri, bukan karena management decision yang berbeda.
APQC dalam guidance mengenai core-process improvement menyarankan organization melakukan standardization sebelum improvement agar perubahan dapat diterapkan secara lebih konsisten antar-function, region, dan division. APQC juga menekankan bahwa necessary variation tetap dapat dipertahankan pada procedure atau standard-work level, sementara governance menentukan kapan variasi tersebut memang justified.
Ini sejalan dengan classification Crocodic: yang perlu dihilangkan bukan seluruh variation, tetapi accidental variation yang tidak lagi menghasilkan value.
Standardization Tidak Berarti Semua Cabang Harus Bekerja Secara Identik
Standardization sering mendapat resistance karena dianggap sebagai upaya headquarters memaksakan satu cara kerja kepada seluruh organization. Kekhawatiran ini valid jika standardization dilakukan tanpa memahami local business condition.
Enterprise tidak membutuhkan seluruh orang melakukan setiap detail process secara identik.
Yang dibutuhkan adalah appropriate level of standardization.
Sebagian process perlu standardized pada level outcome, data definition, control, dan interface, sementara detail execution dapat tetap berbeda. Misalnya semua business unit harus menggunakan customer ID standard yang sama agar data dapat diintegrasikan, tetapi cara local sales team melakukan customer engagement tidak perlu identik. Semua subsidiary mungkin perlu mengikuti common procurement control, tetapi regulatory document dapat berbeda per-country.
APQC menekankan dalam Appropriate Process Standardization bahwa standardization perlu mempertimbangkan context-driven variants dan berbagai process component seperti organization, data, function, deliverable, dan control flow. Artinya, targetnya bukan uniformity pada semua detail, melainkan konsistensi pada layer yang memang dibutuhkan untuk menghasilkan efficiency, interoperability, dan governance.
Microsoft juga memberikan warning bahwa standardisasi yang berlebihan dapat mengurangi flexibility. Karena itu, organization perlu mengidentifikasi area di mana consistency menghasilkan business value dan area di mana variation memang diperlukan.
Standardization yang baik bukan menghilangkan local intelligence.
Ia menghilangkan local complexity yang tidak memiliki alasan bisnis cukup kuat.
Process Variance Menjadi Hambatan ketika Enterprise Ingin Scale
Perusahaan dengan tiga cabang mungkin masih dapat mempertahankan process berbeda melalui coordination manual. Ketika organization berkembang menjadi puluhan branch atau multiple subsidiary, economics berubah.
Setiap variation harus dilatih kepada employee baru. Setiap software change harus diuji pada lebih banyak scenario. Report harus mengakomodasi definisi berbeda. Cross-unit employee transfer menjadi lebih sulit karena cara kerja berbeda. Shared-services organization membutuhkan lebih banyak specialist karena satu process memiliki banyak version. Integration juga semakin rumit karena state dan data meaning tidak konsisten.
Di titik ini, process variance berubah dari local flexibility menjadi scale constraint.
Microsoft menyebut scalability sebagai salah satu manfaat process standardization karena common process memberikan foundation yang lebih konsisten untuk growth dan expansion. (Microsoft Learn) McKinsey juga pernah menunjukkan dalam konteks cross-functional collaboration bahwa variasi operating model yang terlalu banyak antar-business dan geography dapat menghambat collaboration, sharing capability, dan economies of scale pada technology. (McKinsey – Making Collaboration Across Functions a Reality)
Karena itu, scale readiness tidak hanya perlu melihat infrastructure dan application performance. Enterprise juga perlu melihat seberapa banyak operational variation yang harus dibawa ketika bisnis berkembang.
System dapat technically scale ke jutaan transaction.
Tetapi operating model mungkin tidak dapat scale jika setiap unit memerlukan treatment berbeda.
Process Mining Membantu Memisahkan Documented Variation dan Actual Variation
Salah satu tantangan standardization adalah organization sering tidak mengetahui berapa banyak process variant yang sebenarnya terjadi.
SOP dapat menyebut satu workflow. Workshop dengan stakeholder mungkin menghasilkan tiga variant. Tetapi event data dapat menunjukkan puluhan actual paths karena employee melakukan rework, manual bypass, additional approval, atau workaround yang tidak tercantum pada dokumentasi.
Di sinilah Process Mining: Melihat Bottleneck yang Tidak Terlihat menjadi relevan. Process mining memungkinkan organization melihat actual execution berdasarkan event log sehingga variation dapat dianalisis berdasarkan evidence, bukan hanya interview.
Enterprise kemudian dapat melihat process mana yang benar-benar dominan, variant mana yang hanya terjadi sesekali, variant mana yang mempunyai cycle time buruk, dan variation apa yang menyebabkan rework atau exception tinggi.
APQC juga menempatkan process assessment sebagai tahap awal standardization, karena enterprise perlu memahami current process dan context-driven variant sebelum menentukan standard model.
Ini penting karena tanpa evidence, standardization discussion sering berubah menjadi political negotiation antar-unit.
Semua unit merasa process mereka unik.
Data membantu memindahkan diskusi dari “cara kami lebih baik” menjadi “variation mana yang benar-benar menghasilkan business outcome berbeda?”
Software Configuration Seharusnya Menjadi Buffer sebelum Customization
Tidak semua legitimate variation membutuhkan custom development.
Banyak enterprise process dapat menggunakan common architecture dengan configuration untuk threshold, approval level, SLA, tax treatment, role, product, region, atau entity. Configuration membuat variation tetap tersedia tanpa menciptakan branch logic yang terlalu dalam pada source code.
Ini menghasilkan hierarchy yang sehat:
Standard Process → Configuration → Customization
Standard process digunakan selama common design cukup memenuhi kebutuhan. Configuration dipakai ketika variation predictable dan dapat dikelola sebagai parameter. Customization baru digunakan ketika requirement memang tidak dapat dipenuhi melalui common model dan mempunyai business justification yang cukup kuat.
Pendekatan ini sangat penting pada Enterprise Application Integration karena system integration menjadi jauh lebih sulit ketika masing-masing business unit tidak hanya menggunakan application berbeda, tetapi juga mempunyai semantics dan process state berbeda.
Misalnya satu unit mengartikan “approved” sebagai final approval, sementara unit lain masih membutuhkan finance review setelah status tersebut. Secara teknis data dapat dipindahkan melalui API, tetapi integration tidak menghasilkan common operational meaning.
Itulah sebabnya integration strategy tidak dapat dipisahkan sepenuhnya dari process standardization.
API menghubungkan system.
Standardization membantu memastikan system yang dihubungkan berbicara mengenai business process yang sama.
Jangan Mengotomasi Variation yang Sebenarnya Harus Dihilangkan
Automation sering menjadi titik di mana process variance berubah menjadi technology debt.
Ketika team melihat lima workflow berbeda, response yang mudah adalah mengotomasi kelimanya. Setiap flow dibuat, rule ditambahkan, dan process menjadi digital. Project dinilai berhasil karena manual work berkurang.
Namun pertanyaan yang lebih strategis belum dijawab: apakah kita seharusnya memiliki lima workflow tersebut sejak awal?
Jika empat variasi hanya muncul karena kebiasaan department, automation justru membuat accidental variation lebih durable. Perusahaan sekarang bukan hanya memiliki process yang berbeda, tetapi juga harus mempertahankan automation logic untuk setiap variation tersebut.
Inilah alasan Business Process Automation Enterprise perlu dimulai dari process suitability, bukan hanya technical feasibility.
Microsoft dalam process-standardization guidance bahkan melihat technology implementation sebagai opportunity untuk melakukan standardization karena banyak process memang perlu berubah ketika enterprise mengadopsi platform baru. Dengan kata lain, implementation bukan hanya kesempatan untuk mendigitalisasi current process; implementation juga dapat menjadi momentum untuk mempertanyakan process yang sebenarnya tidak lagi perlu dipertahankan.
Prinsip Crocodic sederhana: jangan gunakan automation untuk membuat process yang tidak perlu menjadi lebih cepat.
Process Variance Juga Menciptakan Data Variance
Ketika process berbeda, data yang dihasilkan juga cenderung berbeda.
Business unit menggunakan status berbeda. Cabang mempunyai definition customer berbeda. Department tertentu mengisi field yang tidak digunakan department lain. Approval reason tidak menggunakan classification yang sama. Transaction milestone berbeda.
Akibatnya, management memperoleh satu enterprise system tetapi tidak selalu memperoleh satu enterprise truth.
Report memerlukan additional mapping. KPI sulit dibandingkan. Benchmark antar-unit menjadi tidak fair karena process definition berbeda. AI dan analytics juga menghadapi training atau context data yang tidak konsisten.
Process standardization karena itu tidak hanya menghasilkan operational consistency. Ia juga memperbaiki semantic consistency.
APQC Process Classification Framework dikembangkan antara lain untuk memberikan common language bagi organisasi dalam mendefinisikan, membandingkan, dan meningkatkan business process. Common process language sangat penting karena improvement dan benchmarking menjadi lebih sulit ketika setiap function menggunakan definition berbeda untuk aktivitas yang serupa.
Dari technology perspective, common terminology juga memperkecil translation layer yang harus dibuat di antara application, dashboard, automation, dan AI.
Semakin banyak process meaning distandardisasi, semakin sedikit technology harus menebak context.
Variation Governance Harus Terjadi Sebelum Requirement Menjadi Backlog
Salah satu alasan process variance terus bertambah adalah tidak adanya governance pada titik request.
Business unit meminta workflow berbeda. Product Owner menulis user story. Developer memperkirakan effort. Feature kemudian masuk backlog. Semua orang membahas “bagaimana membuatnya”, tetapi hampir tidak ada yang mempunyai mandate untuk bertanya “apakah variation ini seharusnya ada?”
Karena itu, enterprise membutuhkan Variation Governance sebelum local requirement menjadi permanent technology complexity.
Dalam working model Crocodic, setiap significant variation perlu menjawab empat pertanyaan: apa driver-nya, apa business justification-nya, apakah outcome berbeda memang dibutuhkan, dan berapa long-term complexity cost yang diciptakan.
Jika justification tidak cukup, pilih Standardize. Jika valid dan predictable, pertimbangkan Configure. Jika variation benar-benar mandatory atau strategic dan configuration tidak memadai, baru pilih Customize.
APQC dalam performance-improvement guidance bahkan menekankan bahwa process variation perlu di-govern, bukan sekadar dianggap hilang melalui standardization. Regulation, geography, equipment, atau customer specification dapat menjadi legitimate driver, tetapi organization tetap membutuhkan mechanism untuk menilai case by case apakah variation memang justified.
Variation Governance dengan demikian bukan centralization bureaucracy.
Ia adalah mechanism untuk melindungi enterprise dari complexity yang tumbuh tanpa business return yang sepadan.
Crocodic Perspective: Custom Software Harus Mengikuti Business Differentiation, Bukan Historical Habit
Custom enterprise software mempunyai keunggulan karena dapat mengikuti operating model yang tidak dapat dipenuhi oleh generic platform. Namun flexibility tersebut juga menciptakan risk: organization menjadi terlalu mudah meminta technology mengikuti setiap existing process tanpa terlebih dahulu mempertanyakan apakah process tersebut layak dipertahankan.
Dalam perspective Crocodic, customization perlu mengikuti:
Core Process → Local Variation → Variation Driver → Business Justification → Complexity Cost → Standardize / Configure / Customize
Sementara variation-nya dapat diklasifikasikan menjadi:
Mandatory Variation → Strategic Variation → Accidental Variation
Mandatory dan Strategic Variation dapat memiliki alasan kuat untuk tetap ada. Accidental Variation adalah kandidat utama untuk standardization.
Framework ini juga memberikan perspektif yang berbeda terhadap digital transformation. Target transformation bukan membuat semua process identik. Targetnya adalah menciptakan operating model yang cukup standardized untuk scale, tetapi cukup flexible untuk mempertahankan differentiation yang benar-benar bernilai.
Microsoft menekankan manfaat standardization sekaligus risiko kehilangan flexibility jika standardisasi dilakukan terlalu rigid. APQC menekankan appropriate standardization yang tetap mempertimbangkan context-driven process variants. Keduanya menunjukkan bahwa question yang tepat bukan “standard atau custom?”, tetapi “di layer mana standardization memberikan value dan di layer mana variation memang dibutuhkan?”
Bagi Crocodic, technology seharusnya mengikuti jawaban tersebut.
Kesimpulan
Process Variance merupakan bagian normal dari enterprise operation. Business unit, cabang, entity, market, dan customer memang tidak selalu membutuhkan process yang identik. Namun ketika setiap difference diterima sebagai permanent requirement tanpa business justification, variation mulai menciptakan technology complexity yang menghambat scalability.
Software harus mempertahankan lebih banyak rule. Testing semakin luas. Integration semakin rumit. Reporting kehilangan common definition. Automation mempunyai lebih banyak branch. User training berbeda antar-unit. Perubahan yang seharusnya sederhana menjadi semakin mahal karena setiap modification harus mempertimbangkan banyak process variant.
Karena itu, enterprise tidak perlu menghapus seluruh variation. Organization perlu membedakan Mandatory Variation, Strategic Variation, dan Accidental Variation, kemudian menentukan response melalui:
Core Process → Local Variation → Variation Driver → Business Justification → Complexity Cost → Standardize / Configure / Customize
Standardize ketika variation tidak lagi memiliki alasan kuat. Configure ketika perbedaan valid tetapi masih predictable. Customize ketika variation benar-benar menjadi bagian dari regulatory requirement atau business differentiation yang layak dilindungi.
Pada akhirnya, custom software tidak seharusnya menjadi museum dari seluruh cara kerja yang pernah ada di perusahaan.
Technology seharusnya membantu enterprise mempertahankan perbedaan yang menciptakan value sekaligus menghilangkan perbedaan yang hanya menciptakan complexity.
Karena kemampuan software untuk mengikuti semua permintaan bukan ukuran keberhasilan transformation.
Ukuran yang lebih penting adalah apakah perusahaan berhasil membangun operating model yang lebih sederhana untuk dijalankan, lebih mudah diintegrasikan, lebih murah untuk diubah, dan tetap cukup flexible untuk mempertahankan hal-hal yang benar-benar membuat bisnis berbeda.
Discussion