Dalam software development, menentukan apakah sebuah feature selesai biasanya relatif jelas. Form dapat disubmit. Data berhasil disimpan. API memberikan response yang benar. User dengan role tertentu memiliki akses sesuai permission. Notification terkirim. Automated test berhasil. Performance memenuhi requirement. Setelah seluruh acceptance criteria terpenuhi, feature dapat dianggap selesai dan development bergerak ke pekerjaan berikutnya.<\/p>\n\n\n\n
Masalah muncul ketika organisasi menggunakan definisi \u201cselesai\u201d<\/strong> tersebut untuk menjawab pertanyaan yang sebenarnya berbeda: apakah investment software ini berhasil?<\/strong><\/p>\n\n\n\n Sebuah workflow automation dapat bekerja tanpa error tetapi cycle time tetap sama. Dashboard dapat menampilkan data real-time tetapi decision management tetap terlambat. AI assistant dapat digunakan ribuan kali tetapi manual workload tidak berkurang. Mobile application dapat memiliki adoption tinggi tetapi process yang menjadi alasan pembangunannya tetap menghasilkan bottleneck. Dalam semua kasus tersebut, software dapat dinyatakan berhasil secara teknis sementara business case-nya belum terbukti.<\/p>\n\n\n\n Di sinilah enterprise membutuhkan distinction antara Definition of Done<\/strong> dan apa yang dalam working framework Crocodic dapat disebut Definition of Value<\/strong>.<\/p>\n\n\n\n Scrum Guide 2020 mendefinisikan Definition of Done<\/em> sebagai deskripsi formal mengenai kondisi sebuah Increment ketika telah memenuhi ukuran kualitas yang diperlukan untuk product. Ketika suatu Product Backlog Item memenuhi Definition of Done, sebuah Increment lahir. Tujuan konsep tersebut adalah menciptakan transparansi mengenai pekerjaan yang benar-benar selesai dan usable. Panduan Scrum Scrum Guide 2020<\/a><\/p>\n\n\n\n Itu merupakan discipline engineering yang sangat penting. Namun Definition of Done tidak dimaksudkan untuk membuktikan bahwa business outcome telah terealisasi.<\/p>\n\n\n\n Sebuah Increment dapat Done<\/strong> hari ini, sementara value-nya baru dapat diketahui beberapa minggu atau bulan kemudian.<\/p>\n\n\n\n Traditional acceptance criteria umumnya berfokus pada behavior software. Jika user memilih action A, system harus melakukan B. Jika request memiliki kondisi tertentu, workflow harus menuju approver tertentu. Jika API menerima payload yang valid, data harus berhasil diproses. Criteria semacam ini sangat penting karena tanpa technical acceptance, engineering team tidak memiliki shared understanding mengenai behavior yang dianggap benar.<\/p>\n\n\n\n Namun business-impact-oriented development membutuhkan layer lain.<\/p>\n\n\n\n Misalnya perusahaan membangun automated approval routing karena approval cycle terlalu lambat. Technical acceptance dapat berbunyi: request dengan nominal tertentu otomatis diarahkan kepada approver sesuai matrix<\/em>. Ketika routing tersebut berfungsi, feature layak diterima.<\/p>\n\n\n\n Tetapi alasan bisnis membangunnya mungkin adalah mengurangi average approval time dari kondisi baseline menuju target tertentu.<\/p>\n\n\n\n Maka terdapat dua pertanyaan berbeda:<\/p>\n\n\n\n Technical Acceptance:<\/strong> Apakah routing bekerja sesuai design?<\/p>\n\n\n\n Outcome Acceptance:<\/strong> Apakah keberadaan routing membantu approval cycle bergerak menuju target?<\/p>\n\n\n\n Kedua pertanyaan tersebut tidak boleh dicampur.<\/p>\n\n\n\n Jika technical acceptance gagal, engineering masih memiliki pekerjaan.<\/p>\n\n\n\n Jika technical acceptance berhasil tetapi outcome tidak berubah, diagnosis berikutnya berbeda. Bisa jadi user belum mengadopsi workflow baru. Bisa jadi root cause awal salah. Bisa jadi bottleneck berpindah ke tahap berikutnya. Bisa jadi automation hanya mengurangi sebagian kecil total waiting time.<\/p>\n\n\n\n Dengan memisahkan keduanya, perusahaan dapat menghindari kesimpulan sederhana bahwa software berhasil = business problem selesai<\/strong>.<\/p>\n\n\n\n Dalam pendekatan Crocodic, keberhasilan software dapat dilihat melalui empat layer:<\/p>\n\n\n\n Definition of Done \u2192 Definition of Adoption \u2192 Definition of Outcome \u2192 Definition of Value<\/strong><\/p>\n\n\n\n Definition of Done<\/strong> memastikan technology intervention benar-benar bekerja, usable, secure, dan memenuhi quality requirement. Definition of Adoption<\/strong> melihat apakah intended user atau process benar-benar menggunakan capability tersebut. Definition of Outcome<\/strong> melihat apakah behavior atau operational performance yang menjadi target mulai berubah. Definition of Value<\/strong> menilai apakah perubahan tersebut cukup meaningful untuk menghasilkan benefit terhadap bisnis.<\/p>\n\n\n\n Keempat layer ini memberikan level evidence yang berbeda.<\/p>\n\n\n\n Bayangkan perusahaan membangun automated reconciliation.<\/p>\n\n\n\n Pada level Done, matching engine berhasil bekerja sesuai rule.<\/p>\n\n\n\n Pada level Adoption, majority transaction benar-benar diproses melalui automated flow.<\/p>\n\n\n\n Pada level Outcome, manual reconciliation volume turun.<\/p>\n\n\n\n Pada level Value, team dapat memproses transaction volume yang lebih besar tanpa kenaikan manual workload yang sebanding, atau operational cost benar-benar berkurang.<\/p>\n\n\n\n Sekarang organization dapat melihat dengan jelas di mana value chain berhenti.<\/p>\n\n\n\n Jika software Done tetapi Adoption rendah, masalah kemungkinan berada pada rollout, usability, process, atau change management.<\/p>\n\n\n\n Jika Adoption tinggi tetapi Outcome tidak berubah, hypothesis mengenai causal relationship perlu diperiksa.<\/p>\n\n\n\n Jika Outcome berubah tetapi Value belum material, mungkin magnitude improvement belum cukup besar atau downstream economics berbeda dari assumption awal.<\/p>\n\n\n\n Inilah keuntungan utama outcome-based acceptance: bukan hanya memberi score keberhasilan, tetapi membantu menemukan di layer mana expected value tidak terwujud<\/strong>.<\/p>\n\n\n\n Penting untuk menjaga konsep ini agar tidak berlebihan. Kita tidak perlu memasukkan seluruh business KPI ke dalam Definition of Done engineering.<\/p>\n\n\n\n Misalnya sebuah feature dimaksudkan meningkatkan conversion. Engineering team tidak seharusnya dilarang menyatakan Increment Done sampai conversion meningkat, karena conversion dipengaruhi berbagai faktor di luar control developer.<\/p>\n\n\n\n Scrum Guide sendiri menempatkan Definition of Done sebagai quality state dari Increment, bukan measurement terhadap seluruh business impact. Panduan Scrum<\/a><\/p>\n\n\n\n Karena itu, Crocodic tidak menyarankan mengganti technical acceptance dengan outcome acceptance.<\/p>\n\n\n\n Yang dibutuhkan adalah dua level governance yang berbeda<\/strong>.<\/p>\n\n\n\n Software tetap membutuhkan Definition of Done agar quality tidak ambigu.<\/p>\n\n\n\n Investment membutuhkan Definition of Value agar business success juga tidak ambigu.<\/p>\n\n\n\n Prinsipnya:<\/p>\n\n\n\n Technical acceptance menentukan apakah software layak digunakan. Outcome acceptance menentukan apakah software layak dianggap berhasil sebagai business intervention.<\/strong><\/p>\n\n\n\n Perbedaan ini penting terutama dalam kontrak vendor. Business KPI yang dipengaruhi pricing, organizational policy, user behavior, market condition, dan faktor lain tidak selalu adil dijadikan acceptance criteria contractual bagi engineering vendor.<\/p>\n\n\n\n Namun technology partner tetap perlu memahami outcome tersebut dan mendesain solution agar contribution terhadapnya dapat diukur.<\/p>\n\n\n\n Go-live mudah menjadi pusat gravitasi project. Timeline dibuat menuju launch date. Management meminta progress sampai production. Vendor mengukur completion berdasarkan deployment. Setelah system berhasil digunakan, project dianggap selesai.<\/p>\n\n\n\n Dari perspective delivery, ini valid.<\/p>\n\n\n\n Dari perspective business impact, go-live justru sering menjadi awal measurement window<\/strong>.<\/p>\n\n\n\n Sebelum production, organisasi baru memiliki expected value. Setelah user menggunakan system dalam real workflow, evidence mulai tersedia.<\/p>\n\n\n\n Misalnya system baru dibuat untuk mengurangi order-processing cycle. Pada hari go-live, organization belum mengetahui apakah target tersebut benar-benar tercapai. User membutuhkan waktu beradaptasi. Volume transaction perlu cukup representatif. Exception mulai terlihat. Integration berjalan di kondisi riil. Operational behavior dapat berbeda dari testing environment.<\/p>\n\n\n\n Karena itu:<\/p>\n\n\n\n Go-Live \u2260 Value Realized<\/strong><\/p>\n\n\n\n Go-live membuktikan bahwa capability sudah tersedia.<\/p>\n\n\n\n Value realization membuktikan bahwa capability tersebut telah mengubah kondisi bisnis.<\/p>\n\n\n\n PMI menggunakan konsep serupa dalam Benefits Realization Management. Framework PMI mencakup identifikasi expected benefits, delivery benefits selama execution, dan sustainability benefit setelah project berakhir dan ownership berpindah ke business unit. Institute Manajemen Proyek PMI Benefits Realization Management Framework<\/a><\/p>\n\n\n\n Ini menjelaskan mengapa business case seharusnya tidak ditutup secara otomatis ketika deployment selesai.<\/p>\n\n\n\n Tidak mungkin menyatakan bahwa sesuatu membaik tanpa mengetahui kondisi sebelumnya.<\/p>\n\n\n\n Jika software dibuat untuk mempercepat processing time, perusahaan perlu mengetahui baseline. Jika dibuat untuk menurunkan manual work, manual effort sebelum implementation perlu dipahami. Jika objective-nya mengurangi error, error rate existing perlu diketahui.<\/p>\n\n\n\n Tanpa baseline, seluruh discussion setelah implementation menjadi subjektif.<\/p>\n\n\n\n Business mengatakan jauh lebih cepat.<\/p>\n\n\n\n User mengatakan sedikit lebih nyaman.<\/p>\n\n\n\n IT mengatakan system lebih modern.<\/p>\n\n\n\n Vendor menunjukkan seluruh feature selesai.<\/p>\n\n\n\n Namun tidak ada common reference untuk menentukan magnitude perubahan.<\/p>\n\n\n\n GOV.UK Service Manual merekomendasikan organisasi menetapkan baseline performance dan menilai perubahan service terhadap baseline tersebut. Guidance yang sama menyarankan measurement dirancang sejak service dibangun, bukan baru dipikirkan setelah implementation. GOV.UK GOV.UK \u2014 How to Set Performance Metrics for Your Service<\/a><\/p>\n\n\n\n Karena itu, Outcome-Based Acceptance Criteria sebenarnya dimulai sebelum development<\/strong>.<\/p>\n\n\n\n Saat business case disusun, team perlu mengetahui:<\/p>\n\n\n\n baseline-nya apa, target-nya apa, data source-nya apa, dan kapan measurement dianggap cukup representatif?<\/strong><\/p>\n\n\n\n Jika pertanyaan tersebut baru muncul setelah go-live, organization berisiko tidak memiliki data untuk membuktikan apapun.<\/p>\n\n\n\n Traditional acceptance criteria sering berbentuk binary:<\/p>\n\n\n\n pass atau fail.<\/strong><\/p>\n\n\n\n Business outcome tidak selalu dapat diperlakukan seperti itu karena value biasanya muncul melalui chain.<\/p>\n\n\n\n Misalnya application dibuat untuk menurunkan maintenance downtime.<\/p>\n\n\n\n Technology intervention pertama adalah digital inspection.<\/p>\n\n\n\n Namun digital inspection tidak secara langsung menurunkan downtime. Causal chain-nya dapat terlihat seperti:<\/p>\n\n\n\n Digital Inspection \u2192 Faster Issue Submission \u2192 Faster Work Order Creation \u2192 Faster Technician Response \u2192 Lower Repair Time \u2192 Reduced Downtime<\/strong><\/p>\n\n\n\n Setiap titik memiliki evidence masing-masing.<\/p>\n\n\n\n Application dapat bekerja dengan sempurna, tetapi jika work order masih dibuat manual satu hari kemudian, downtime tidak berubah.<\/p>\n\n\n\n Outcome-Based Acceptance Criteria karena itu perlu menjaga causal traceability<\/strong> antara technology dan business impact.<\/p>\n\n\n\n Dalam working framework Crocodic:<\/p>\n\n\n\n Feature \u2192 Capability \u2192 Adoption \u2192 Process Change \u2192 Outcome \u2192 Business Impact<\/strong><\/p>\n\n\n\n Kita tidak menuntut satu feature langsung menghasilkan profit.<\/p>\n\n\n\n Kita memastikan ada chain yang dapat diamati dari feature menuju perubahan yang memang relevan.<\/p>\n\n\n\n Jika chain tersebut putus, team tahu layer mana yang perlu diperiksa.<\/p>\n\n\n\n Software tidak menghasilkan business impact hanya karena tersedia.<\/p>\n\n\n\n User dapat tetap menggunakan spreadsheet.<\/p>\n\n\n\n Manager dapat tetap meminta report lewat chat.<\/p>\n\n\n\n Operations dapat tetap melewati workflow baru.<\/p>\n\n\n\n Department dapat menjalankan system lama secara parallel tanpa batas.<\/p>\n\n\n\n Karena itu, adoption perlu mempunyai criteria sendiri.<\/p>\n\n\n\n Namun adoption tidak hanya berarti login atau jumlah active user.<\/p>\n\n\n\n User dapat login setiap hari tetapi tetap menyelesaikan critical task melalui process lama.<\/p>\n\n\n\n Measurement yang lebih berguna adalah behavioral adoption<\/strong>: apakah activity yang menjadi target benar-benar berpindah menuju capability baru?<\/p>\n\n\n\n Jika system dibuat untuk digital inspection, pertanyaannya bukan hanya berapa inspector login, tetapi berapa proporsi inspection relevant yang dilakukan melalui process baru.<\/p>\n\n\n\n Jika automation dibuat untuk invoice matching, bukan hanya berapa kali feature terbuka, tetapi berapa transaction yang benar-benar masuk automated path.<\/p>\n\n\n\n Ini juga membuat Change Management<\/a> menjadi internal dependency penting. Crocodic sudah memiliki pembahasan mengenai adopsi sistem, dan artikel tersebut memang berada pada inventory existing.<\/p>\n\n\n\n Tetapi adoption sendiri tetap bukan akhir.<\/p>\n\n\n\n User dapat menggunakan system dan outcome tetap tidak berubah.<\/p>\n\n\n\n Outcome berada satu layer setelah adoption.<\/p>\n\n\n\n Jika feature digunakan, apakah process mengalami perubahan yang diharapkan?<\/p>\n\n\n\n Untuk approval automation, outcome dapat berupa waiting time yang lebih pendek.<\/p>\n\n\n\n Untuk integration, outcome dapat berupa reduction pada duplicate input dan reconciliation.<\/p>\n\n\n\n Untuk inspection application, outcome dapat berupa faster issue reporting.<\/p>\n\n\n\n Untuk AI assistant, outcome dapat berupa shorter resolution time atau reduced manual research.<\/p>\n\n\n\n GOV.UK menyarankan metric diturunkan dari purpose dan benefit service, kemudian hypothesis digunakan untuk menentukan apa yang perlu diukur. Mereka juga merekomendasikan continuous measurement agar organisasi dapat melihat trend dan membedakan perubahan yang disebabkan intervention dari variasi lain. GOV.UK<\/a><\/p>\n\n\n\n Konsep ini sangat sesuai untuk enterprise.<\/p>\n\n\n\n Outcome criteria tidak perlu seratus metric.<\/p>\n\n\n\n Justru terlalu banyak KPI membuat attribution semakin kabur.<\/p>\n\n\n\n Idealnya setiap intervention memiliki beberapa evidence yang sangat dekat dengan causal chain.<\/p>\n\n\n\n Misalnya objective-nya mengurangi processing cycle.<\/p>\n\n\n\n Metric utama: end-to-end cycle time.<\/p>\n\n\n\n Leading evidence: waiting time pada step yang diintervensi.<\/p>\n\n\n\n Adoption evidence: proportion process yang menggunakan capability baru.<\/p>\n\n\n\n Sekarang management dapat melihat bukan hanya hasil akhirnya<\/strong>, tetapi mengapa hasil tersebut terjadi atau tidak terjadi.<\/p>\n\n\n\n Tidak semua improvement otomatis menghasilkan business value yang material.<\/p>\n\n\n\n Bayangkan processing time turun dari delapan jam menjadi tujuh jam lima puluh menit. Outcome secara statistik mungkin membaik, tetapi apakah perubahan sepuluh menit benar-benar berarti bagi business process?<\/p>\n\n\n\n Sebaliknya, penurunan processing time kecil pada critical high-volume process dapat menghasilkan value besar.<\/p>\n\n\n\n Definition of Value karena itu perlu menerjemahkan process outcome menuju significance bagi organisasi.<\/p>\n\n\n\n Value dapat berupa:<\/p>\n\n\n\n reduced operational cost, protected margin, additional capacity, reduced downtime, avoided risk, improved customer conversion, shorter cash cycle, faster decision, atau strategic capability lain.<\/p>\n\n\n\n Tidak semuanya harus diubah menjadi rupiah dengan false precision.<\/p>\n\n\n\n Yang dibutuhkan adalah business significance<\/strong>.<\/p>\n\n\n\n PMI menekankan bahwa benefits realization menghubungkan organizational strategy dengan project deliverables dan success measurement, serta perlu berlanjut sampai benefit benar-benar realized dan sustained. Institute Manajemen Proyek<\/a><\/p>\n\n\n\n Itulah perbedaan outcome dengan value.<\/p>\n\n\n\n Outcome mengatakan:<\/p>\n\n\n\n \u201cProcessing time turun.\u201d<\/strong><\/p>\n\n\n\n Value mengatakan:<\/p>\n\n\n\n \u201cPenurunan tersebut memungkinkan team memproses volume lebih besar tanpa penambahan resource yang sebanding.\u201d<\/strong><\/p>\n\n\n\n Untuk menyederhanakan governance, Crocodic dapat menggunakan framework berikut:<\/p>\n\n\n\nTechnical Acceptance dan Business Acceptance Menjawab Pertanyaan yang Berbeda<\/strong><\/h2>\n\n\n\n
Crocodic Outcome Acceptance Chain<\/strong><\/h2>\n\n\n\n
Definition of Done Tidak Perlu Diubah Menjadi Business KPI<\/strong><\/h2>\n\n\n\n
Go-Live Adalah Milestone, Bukan Bukti Value<\/strong><\/h2>\n\n\n\n
Outcome Acceptance Membutuhkan Baseline yang Sudah Disepakati<\/strong><\/h2>\n\n\n\n
Dari Acceptance Criteria menuju Acceptance Chain<\/strong><\/h2>\n\n\n\n
Definition of Adoption: Apakah Capability Benar-Benar Masuk ke Cara Kerja?<\/strong><\/h2>\n\n\n\n
Definition of Outcome: Apakah Operational Performance Benar-Benar Bergerak?<\/strong><\/h2>\n\n\n\n
Definition of Value: Apakah Outcome Cukup Penting bagi Bisnis?<\/strong><\/h2>\n\n\n\n
Crocodic Outcome-Based Acceptance Framework<\/strong><\/h2>\n\n\n\n