Dalam hampir setiap proyek software, ownership terhadap pekerjaan biasanya cukup jelas. Developer bertanggung jawab membangun system. QA memastikan quality. Project Manager mengelola timeline dan coordination. IT memastikan infrastructure tersedia. Vendor memenuhi scope yang telah disepakati. Business user memberikan requirement dan melakukan validation. Ketika system berhasil go-live, masing-masing pihak dapat menunjukkan bahwa responsibility mereka telah diselesaikan.
Namun situasinya menjadi jauh lebih rumit ketika pertanyaannya berubah dari “apakah software berhasil dibuat?” menjadi “apakah kondisi bisnis yang menjadi alasan software tersebut dibangun benar-benar berubah?”
Bayangkan sebuah perusahaan membangun approval system dengan tujuan mengurangi processing time. System selesai sesuai requirement, seluruh workflow berfungsi, user sudah menggunakan aplikasi, dan availability tidak bermasalah. Namun enam bulan kemudian, average approval time hampir tidak berubah. Developer dapat menunjukkan bahwa software bekerja. Vendor dapat menunjukkan scope sudah delivered. Business user dapat menunjukkan mereka sudah menggunakan system. IT dapat menunjukkan uptime berada pada target. Semua pihak secara individual terlihat berhasil, tetapi outcome yang menjadi alasan investasi belum tercapai.
Lalu siapa yang bertanggung jawab?
Pertanyaan inilah yang menjadi inti Outcome Ownership. Dalam business-impact-oriented development, software tidak seharusnya hanya memiliki owner terhadap delivery. Enterprise juga membutuhkan ownership terhadap perubahan bisnis yang ingin dihasilkan melalui technology intervention.
McKinsey menempatkan prinsip serupa pada product operating model: product team yang matang merupakan cross-functional team yang menggabungkan business, technology, operations, dan fungsi relevan lainnya, dengan accountability terhadap business outcome dari idea hingga scale. Mereka juga menekankan pentingnya end-to-end ownership agar organisasi mengurangi handoff dan ambiguity antar-function. McKinsey & Company
McKinsey — The Bottom-Line Benefit of the Product Operating Model
Delivery Ownership Tidak Sama dengan Outcome Ownership
Software delivery memiliki output yang relatif mudah diidentifikasi. Application tersedia, integration berjalan, migration selesai, module berhasil dirilis, atau feature berhasil masuk production. Output memiliki acceptance criteria yang dapat diuji sehingga ownership-nya juga relatif mudah ditetapkan.
Business outcome berbeda. Outcome dapat berupa penurunan processing time, pengurangan manual work, peningkatan capacity, penurunan error, peningkatan conversion, percepatan maintenance response, atau improvement lain yang terjadi setelah technology capability masuk ke operational process.
Project Management Institute membedakan output dengan outcome secara eksplisit. Output merupakan hasil yang dihasilkan ketika project selesai, sedangkan business outcome merupakan value, benefit, atau utility yang muncul ketika hasil project tersebut benar-benar mengubah business secara meaningful. Institut Manajemen Proyek
Perbedaan tersebut menjelaskan mengapa accountability terhadap development tidak otomatis menjadi accountability terhadap business impact. Developer dapat mengontrol apakah routing automation bekerja sesuai specification, tetapi developer tidak memiliki authority untuk mengurangi jumlah approval layer pada organizational policy. Vendor dapat membangun reporting system, tetapi vendor tidak memiliki authority untuk memastikan management menggunakan information tersebut dalam decision-making. IT dapat menyediakan integration, tetapi tidak dapat sendirian memastikan business unit berhenti menggunakan spreadsheet parallel.
Karena itu, Outcome Ownership tidak menggantikan Delivery Ownership. Keduanya berada pada layer yang berbeda.
Crocodic Outcome Ownership Chain
Dalam pendekatan Crocodic, ownership dapat dilihat melalui chain:
Business Outcome Owner → Process Owner → Product/Technology Owner → Delivery Owner → Measurement Owner
Kelima peran tersebut tidak selalu harus dipegang lima orang berbeda. Pada organisasi tertentu satu orang dapat memegang beberapa peran. Yang penting adalah setiap layer memiliki accountability yang jelas.
Business Outcome Owner memiliki accountability terhadap kondisi bisnis yang ingin berubah. Ia memastikan outcome tetap relevan, trade-off dapat diputuskan, dan intervention tidak kehilangan hubungan dengan business objective. Process Owner memiliki authority terhadap process, policy, role, dan operational behavior yang menentukan apakah software dapat menghasilkan perubahan. Product atau Technology Owner memastikan capability teknologi benar-benar mendukung outcome dan berkembang berdasarkan evidence. Delivery Owner memastikan intervention dibangun dengan quality, scope, architecture, dan timeline yang sesuai. Measurement Owner menjaga baseline, metric definition, data source, dan evidence agar perusahaan dapat mengetahui apakah outcome benar-benar bergerak.
Struktur ini bukan organizational template universal. Crocodic menggunakannya sebagai diagnostic model untuk menemukan gap accountability.
Jika tidak ada orang yang dapat menjawab “siapa yang bertanggung jawab memastikan business outcome ini tercapai?”, kemungkinan besar outcome tersebut belum benar-benar memiliki owner.
Outcome Owner Harus Memiliki Authority terhadap Levers yang Memengaruhi Outcome
Menunjuk nama seseorang sebagai owner belum cukup. Outcome Owner perlu memiliki influence atau authority terhadap sebagian besar lever yang menentukan outcome.
Misalnya sebuah procurement project menargetkan penurunan approval cycle dari dua hari menjadi beberapa jam. Procurement Director dapat menjadi Outcome Owner karena ia memiliki influence terhadap approval policy, process, operational KPI, dan perubahan behavior team. IT Director dapat menjadi Technology Owner karena memiliki authority terhadap system capability dan integration.
Jika approval tetap lambat karena policy meminta empat approval level, tidak rasional menempatkan engineering manager sebagai satu-satunya accountable party. Engineering tidak memiliki authority untuk menghapus approval layer tersebut.
Prinsip sederhananya:
Accountability tanpa authority menghasilkan ownership semu.
Outcome Owner tidak harus mampu melakukan seluruh pekerjaan sendiri, tetapi harus memiliki cukup authority untuk mengkoordinasikan contributor, mengambil atau mengeskalasikan decision, serta meminta perubahan ketika evidence menunjukkan outcome tidak bergerak.
Inilah alasan ownership business outcome idealnya tidak otomatis diberikan kepada vendor atau IT hanya karena intervention utamanya berbentuk software.
Technology Partner Tidak Bisa Menjamin Seluruh Business Outcome—Tetapi Tetap Harus Bertanggung Jawab terhadap Contribution-nya
Pergeseran ke business impact tidak berarti vendor dapat mengatakan bahwa outcome sepenuhnya urusan client. Sebaliknya, technology partner tetap harus memiliki accountability yang lebih tinggi daripada sekadar “feature sudah selesai”.
Technology partner perlu bertanggung jawab terhadap kualitas solution hypothesis, architecture, usability, reliability, integration, measurement readiness, dan apakah capability yang dikirim secara rasional dapat berkontribusi terhadap intended outcome.
Misalnya sebuah system dibuat untuk mengurangi manual reconciliation. Vendor tidak dapat menjamin total operational saving jika volume, policy, staffing, dan process behavior berada di luar kontrolnya. Tetapi vendor dapat bertanggung jawab memastikan reconciliation yang memang seharusnya dapat diotomasi benar-benar tidak lagi membutuhkan manual processing akibat kekurangan software.
Karena itu, accountability lebih tepat dibagi berdasarkan control boundary.
Business bertanggung jawab terhadap process dan business decision yang berada dalam authority-nya. Technology team bertanggung jawab terhadap technology capability dan technical outcome yang berada dalam authority-nya. Keduanya memiliki shared accountability terhadap causal chain yang menghubungkan software dengan business impact.
Model ini jauh lebih realistis daripada dua ekstrem: vendor hanya bertanggung jawab “sesuai requirement”, atau vendor diminta menjamin seluruh ROI perusahaan.
Shared Accountability Tidak Berarti Tidak Ada Satu Orang yang Accountable
Karena outcome dipengaruhi banyak pihak, organisasi mudah jatuh ke konsep “semua orang bertanggung jawab”. Masalahnya, ketika semua pihak bertanggung jawab secara abstrak, sering kali tidak ada satu pihak yang mengambil decision ketika outcome mulai keluar dari target.
Shared contribution tetap membutuhkan single accountable outcome owner.
McKinsey menggambarkan product teams sebagai cross-functional, tetapi tetap menekankan clear roles, responsibilities, product boundaries, dan end-to-end ownership. Dalam salah satu transformation yang mereka bahas, overlapping ownership antar-business leader justru menciptakan confusion dan coordination overhead sampai organisasi menetapkan single owner pada setiap product. McKinsey & Company
Konsepnya dapat diterjemahkan ke enterprise software. Sales, Operations, IT, Finance, dan vendor semuanya dapat berkontribusi terhadap improvement customer onboarding. Namun organisasi tetap membutuhkan seseorang yang memiliki mandat untuk mengatakan:
“Outcome kita adalah onboarding cycle turun. Metric belum bergerak. Bottleneck sekarang berada pada verification policy. Kita perlu mengubah policy sebelum menambah feature.”
Tanpa owner semacam itu, response paling mudah biasanya adalah membuat backlog baru.
Outcome Owner Berbeda dengan Project Manager
Project Manager memiliki accountability penting terhadap execution: scope, timeline, dependency, risk, communication, dan coordination. Tetapi tidak semua Project Manager memiliki authority terhadap process dan business operating model setelah project selesai.
Itulah alasan Outcome Ownership tidak boleh otomatis disamakan dengan project ownership.
Sebuah project dapat selesai tepat waktu sementara business outcome belum muncul. Project Manager dapat menutup delivery, sementara Business Outcome Owner masih perlu memastikan adoption, operational change, dan realized impact.
PMI sendiri menekankan hubungan antara project execution dan desired business outcome serta perlunya menjaga value creation dalam project, program, dan portfolio decision. Institut Manajemen Proyek
Outcome Owner dan Project Manager dapat bekerja sangat dekat tetapi mengoptimalkan hal yang berbeda. Project Manager bertanya:
“Apakah kita mampu menghasilkan intervention sesuai commitment?”
Outcome Owner bertanya:
“Apakah intervention tersebut masih merupakan cara terbaik untuk mencapai perubahan yang kita inginkan?”
Kadang jawabannya membuat project scope berubah. Karena itu, kedua role perlu memiliki jalur decision yang jelas.
Outcome Owner Juga Berbeda dengan Product Owner
Istilah Product Owner sering digunakan dengan makna yang sangat berbeda antarorganisasi. Pada sebagian team, Product Owner memiliki authority kuat terhadap product strategy dan outcome. Pada team lain, Product Owner lebih banyak berfungsi sebagai backlog manager yang menerjemahkan stakeholder request menjadi user stories.
Dalam model kedua, menjadikan Product Owner otomatis sebagai Business Outcome Owner dapat menciptakan masalah yang sama. Ia memiliki responsibility terhadap backlog tetapi tidak memiliki authority terhadap process, policy, budget, atau business KPI.
Product operating model yang lebih matang bergerak jauh melampaui backlog administration. McKinsey menekankan product manager yang memiliki accountability terhadap business outcomes dari idea, launch, hingga scale dan melakukan measurement terhadap impact untuk mengambil keputusan berbasis data. McKinsey & Company
Karena itu, pertanyaan organisasi bukan sekadar “apakah kita memiliki Product Owner?”, tetapi:
“Apakah role tersebut benar-benar memiliki mandate dan authority untuk mengambil keputusan berdasarkan outcome?”
Jika tidak, Business Outcome Owner tetap perlu didefinisikan secara terpisah.
Outcome Ownership Membutuhkan Causal Chain yang Jelas
Seseorang sulit bertanggung jawab terhadap outcome jika organisasi sendiri tidak dapat menjelaskan bagaimana software diperkirakan menghasilkan outcome tersebut.
Karena itu, ownership perlu mengikuti causal chain:
Technology Capability → User/Process Adoption → Process Change → Outcome KPI → Business Impact
Misalnya company membangun mobile inspection application untuk mempercepat maintenance. Causal chain-nya bukan:
Mobile App → Downtime Turun
Hubungan tersebut terlalu jauh.
Chain yang lebih realistis dapat berupa:
Digital Inspection → Finding Submitted Lebih Cepat → Work Order Dibuat Lebih Cepat → Technician Response Lebih Cepat → Mean Time to Repair Turun → Facility Downtime Berkurang
Sekarang ownership dapat diletakkan dengan lebih akurat. Application team bertanggung jawab memastikan digital inspection dan submission reliable. Maintenance Process Owner bertanggung jawab terhadap work-order process. Operational Manager bertanggung jawab terhadap resource response. Outcome Owner memastikan keseluruhan chain bergerak menuju reduced downtime.
Tanpa causal chain, semua pihak dapat memperdebatkan apakah kegagalan outcome merupakan masalah software atau bisnis. Dengan causal chain, organization dapat melihat titik mana yang tidak bergerak.
Measurement Owner Menjaga Outcome Tidak Berubah Menjadi Opini
Outcome Ownership membutuhkan evidence. Jika metric definition berubah setelah implementation, stakeholder dapat memiliki versi keberhasilan yang berbeda-beda.
Misalnya objective adalah “mengurangi processing time”. Apakah processing time dimulai ketika request dibuat atau ketika staff mulai mengerjakannya? Apakah weekend dihitung? Apakah exception termasuk? Apakah average atau median yang digunakan? Apakah data sebelum dan sesudah implementation berasal dari system yang sama?
Measurement Owner tidak harus menjadi role baru dalam organizational chart. Ia dapat berasal dari analytics, process excellence, finance, product, atau business team. Namun tanggung jawabnya perlu jelas: memastikan baseline, target, metric definition, measurement window, data source, dan reporting method konsisten.
Gartner menggunakan konsep Outcome-Driven Metrics untuk menghubungkan operational technology metrics dengan business outcomes dan membantu CIO membuat prioritization serta investment decision berdasarkan business value. Dalam riset 2026 tentang software engineering, Gartner kembali memperingatkan bahwa operational engineering metrics saja dapat mengoptimalkan investment menuju outcome yang salah jika tidak dihubungkan dengan value. Gartner
Gartner — Outcome-Driven Metrics for the Digital Era
Measurement dengan demikian bukan reporting layer terakhir. Ia menjadi bagian dari accountability.
Adoption Memiliki Owner karena Software yang Tidak Digunakan Tidak Bisa Menghasilkan Outcome
Banyak software project mengalami gap setelah delivery bukan karena feature salah, tetapi karena operating behavior tidak berubah. Application sudah tersedia tetapi team mempertahankan spreadsheet. Automated workflow sudah ada tetapi approval tetap dilakukan melalui chat. Dashboard menyediakan data tetapi meeting tetap menggunakan report manual.
Karena itu, adoption tidak dapat diperlakukan sebagai “urusan user setelah go-live”.
Namun adoption juga tidak bisa dilempar seluruhnya kepada vendor. Adoption dapat membutuhkan training, policy, communication, role adjustment, incentive, process redesign, bahkan keputusan management untuk menghentikan workflow lama.
Di sinilah Process Owner memiliki peran besar. Technology team dapat membuat capability mudah digunakan; Process Owner perlu memastikan operational process benar-benar mengadopsinya.
Crocodic sebelumnya telah membahas layer ini melalui Change Management: Kunci Sukses Adopsi Sistem IT Baru. Outcome Ownership memperluas perspektif tersebut: adoption bukan objective akhir. Adoption merupakan salah satu condition yang diperlukan agar business outcome memiliki kesempatan untuk terjadi.
Siapa yang Menjadi Outcome Owner untuk Project Lintas Divisi?
Ownership menjadi lebih sulit ketika satu outcome melibatkan beberapa department. Misalnya customer onboarding melibatkan Sales, Risk, Operations, Finance, dan IT. Tidak ada satu functional manager yang memiliki authority penuh atas semuanya.
Dalam kondisi seperti ini, Outcome Owner idealnya berada pada level yang memiliki mandate terhadap end-to-end value stream, bukan hanya satu functional step. Bisa berupa business executive, transformation leader, value-stream owner, atau sponsor yang memiliki decision authority lintas fungsi.
Deloitte memberikan perspektif serupa dalam product operating model: cross-functional team perlu diberikan outcome yang jelas dan empowerment yang cukup sehingga decision tidak terus tersangkut pada functional silo. Deloitte
Masalah lintas-divisi tidak dapat diselesaikan hanya dengan menambah coordination meeting. Jika ownership tetap mengikuti silo sementara outcome berjalan end-to-end, setiap department akan mengoptimalkan metric sendiri.
Finance dapat memaksimalkan control. Sales mengoptimalkan conversion. Operations mengoptimalkan workload. IT mengoptimalkan stability. Semua metric dapat membaik sementara onboarding end-to-end tetap lambat.
Outcome Ownership memindahkan pertanyaan dari:
“Apakah department saya sudah melakukan bagiannya?”
menjadi:
“Apakah customer atau business process end-to-end sudah menghasilkan kondisi yang ditargetkan?”
Jangan Memberikan Outcome yang Tidak Bisa Dipengaruhi Team
Business-impact orientation juga dapat salah digunakan dengan menuntut team bertanggung jawab terhadap metric yang terlalu jauh dari control mereka.
Misalnya sebuah internal workflow team diberi target “increase company revenue”. Revenue dapat dipengaruhi price, market demand, sales strategy, competition, macroeconomic condition, product quality, distribution, dan berbagai faktor lain. Menghubungkan satu workflow langsung ke revenue membuat accountability tidak credible.
Outcome perlu cukup dekat dengan intervention agar team dapat memengaruhinya.
Struktur yang lebih sehat adalah:
Team-Controlled Outcome → Process Outcome → Business Contribution
Contohnya, workflow team dapat bertanggung jawab terhadap quote approval cycle. Sales leadership dapat bertanggung jawab terhadap quote-to-close performance. Revenue merupakan aggregate business outcome yang dipengaruhi keduanya plus faktor lain.
Dengan kata lain:
Semakin jauh sebuah metric dari control boundary sebuah team, semakin hati-hati kita menyebutnya accountability.
Ini penting agar business-impact-oriented development tidak berubah menjadi fake attribution.
Outcome Ownership Membuat Scope Discussion Menjadi Lebih Rasional
Dalam feature-driven project, scope discussion biasanya berpusat pada request: stakeholder ingin feature baru, team memperkirakan effort, lalu management memutuskan apakah masuk timeline.
Outcome ownership menambahkan filter yang lebih kuat:
Outcome apa yang dibantu feature ini?
Jika request membantu menutup remaining outcome gap, request memiliki business case yang kuat. Jika merupakan mandatory control, security requirement, atau critical dependency, role-nya juga jelas. Tetapi jika feature tidak memiliki meaningful relationship terhadap active outcome, Outcome Owner memiliki basis untuk menunda atau menolak request meskipun request tersebut berasal dari senior stakeholder.
Ini membuat backlog berubah dari daftar permintaan menjadi portfolio of interventions.
Pada project custom software, discipline tersebut sangat penting karena kemampuan customization hampir tidak terbatas. Custom Enterprise Software Crocodic dapat memberikan fleksibilitas untuk menyesuaikan system dengan business process, tetapi flexibility hanya menjadi advantage jika development tetap memiliki hierarchy terhadap business value. Jika setiap stakeholder request otomatis menjadi feature, custom system mudah mengalami feature bloat.
Outcome Owner berfungsi sebagai penjaga hubungan antara flexibility dan value.
Outcome Ownership Tidak Berakhir ketika Software Go-Live
Ini merupakan distinction penting dari traditional project ownership. Jika owner hanya aktif sampai deployment, outcome kemungkinan kehilangan sponsor tepat ketika measurement yang paling penting baru dimulai.
Setelah go-live, pertanyaan justru berubah:
Apakah user mengadopsi capability? Apakah process berubah? Apakah KPI mulai bergerak? Apakah improvement sesuai target? Jika tidak, di mana causal chain berhenti?
PMI dalam benefits-realization literature menekankan bahwa setiap benefit membutuhkan responsible owner; tanpa owner, commitment terhadap benefit menjadi ambigu. Institut Manajemen Proyek
Outcome Owner karena itu perlu tetap memiliki responsibility selama realization window yang relevan. Tidak selalu berarti ia bekerja setiap hari bersama development team. Namun outcome tetap masuk dalam governance sampai organization memiliki evidence yang cukup bahwa benefit telah muncul atau hypothesis perlu diubah.
Project closure dan outcome closure bukan hal yang sama.
Ketika Outcome Tidak Tercapai, Owner Tidak Otomatis “Disalahkan”
Accountability seharusnya tidak membuat organization takut menjalankan experiment atau mengambil keputusan dengan uncertainty. Software development mengandung hypothesis. Business condition juga dapat berubah.
Outcome Owner bukan orang yang harus “dipersalahkan” ketika target tidak tercapai. Accountability berarti ia bertanggung jawab memastikan outcome tidak dibiarkan tanpa response.
Jika KPI tidak bergerak, owner perlu memimpin diagnosis. Apakah adoption rendah? Apakah root cause sebelumnya salah? Apakah integration belum lengkap? Apakah policy menghambat? Apakah feature digunakan tetapi intervention tidak cukup kuat? Apakah external condition berubah sehingga target tidak lagi relevan?
Outcome Ownership adalah ownership terhadap decision dan learning, bukan janji bahwa seluruh hypothesis akan berhasil.
Ini sangat penting karena jika organization mengasosiasikan outcome accountability dengan punishment, semua team akan memilih target yang aman. Mereka kemudian kembali ke output metric karena output jauh lebih mudah dikontrol.
Outcome Owner Harus Memiliki Hak Menghentikan Development
Salah satu consequence paling powerful dari Outcome Ownership adalah kemampuan mengatakan “cukup”.
Bayangkan roadmap memiliki sepuluh planned features untuk mengurangi processing time. Setelah empat feature pertama dirilis, business KPI sudah mencapai target. Apa yang terjadi dengan enam feature berikutnya?
Dalam feature-driven project, kemungkinan besar semuanya tetap dibangun karena masuk scope.
Dalam impact-oriented development, Outcome Owner dapat bertanya apakah remaining feature masih memiliki incremental value. Beberapa mungkin tetap diperlukan untuk security, reliability, regulation, atau long-term sustainability. Tetapi feature lain dapat ditunda atau dihentikan jika outcome sudah tercapai.
Sebaliknya, jika seluruh planned feature sudah selesai tetapi target belum tercapai, outcome owner juga dapat menolak menutup discussion dengan “project selesai”. Gap yang tersisa perlu dianalisis.
Inilah mengapa Outcome Ownership menjadi prerequisite bagi artikel berikutnya mengenai Marginal Value of Features. Enterprise membutuhkan seseorang yang memiliki authority untuk menentukan kapan additional development masih menciptakan value dan kapan complexity tambahan sudah tidak lagi layak.
Outcome Ownership pada AI Lebih Penting karena Authority Software Semakin Besar
AI memperbesar kebutuhan ownership karena technology tidak hanya menampilkan information tetapi dapat increasingly membantu atau melakukan decision dan action.
Misalnya AI Agent digunakan untuk procurement, customer service, finance, atau maintenance. Technology team dapat bertanggung jawab terhadap model, integration, tool access, reliability, dan observability. Namun siapa yang bertanggung jawab terhadap business outcome dari decision yang dilakukan agent? Siapa yang menentukan acceptable error? Siapa yang memiliki authority untuk mengubah policy? Siapa yang menentukan kapan agent harus meminta human approval?
Gartner pada September 2026 bahkan menekankan governance, business value delivery, project co-ownership, knowledge transfer, dan exit strategy sebagai faktor penting dalam engagement vendor yang membangun agentic AI untuk enterprise. Gartner
Hal ini menunjukkan bahwa semakin autonomous technology menjadi, semakin penting ownership terhadap outcome dan decision boundary tidak menjadi ambigu.
Vendor tidak seharusnya menjadi organizational owner terhadap business decision hanya karena vendor membangun agent. Enterprise tetap perlu memiliki outcome owner dan process owner yang jelas.
Crocodic Perspective: Software Tidak Bisa Sendirian Memiliki Business Outcome
Dalam perspective Crocodic, business-impact-oriented development tidak berarti technology team mengambil alih tanggung jawab seluruh bisnis. Justru pendekatan tersebut membutuhkan pembagian accountability yang lebih presisi.
Framework-nya:
Business Outcome Owner → Process Owner → Product/Technology Owner → Delivery Owner → Measurement Owner
Lalu seluruh role tersebut bekerja di atas causal chain:
Technology Capability → Adoption → Process Change → Outcome KPI → Business Impact
Technology partner harus accountable terhadap capability yang dibangun dan contribution hypothesis-nya. Process Owner accountable terhadap perubahan process yang berada dalam authority-nya. Business Outcome Owner menjaga outcome end-to-end, sedangkan Measurement Owner menjaga evidence.
Inilah perbedaan antara shared contribution dan blurred accountability.
McKinsey menekankan cross-functional teams, clear role definition, end-to-end ownership, dan accountability terhadap business outcomes sebagai karakter penting product operating model. Gartner menggunakan outcome-driven metrics untuk menghubungkan technology operation dengan business value. PMI membedakan project output dengan business outcome dan menekankan pentingnya ownership dalam benefits realization. McKinsey & Company
Dalam konteks Crocodic, prinsipnya sederhana:
Business impact tidak boleh menjadi tanggung jawab “semua orang” sampai akhirnya tidak menjadi tanggung jawab siapa pun.
Kesimpulan
Enterprise software memiliki banyak owner terhadap aktivitas. Ada owner untuk backlog, project, infrastructure, application, testing, vendor management, dan delivery. Namun tidak semua organisasi memiliki jawaban yang sama jelas terhadap pertanyaan:
Siapa yang bertanggung jawab memastikan alasan bisnis dari investment tersebut benar-benar tercapai?
Outcome Ownership mengisi gap tersebut.
Dalam working model Crocodic, ownership dapat dilihat melalui:
Business Outcome Owner → Process Owner → Product/Technology Owner → Delivery Owner → Measurement Owner
dan dievaluasi melalui chain:
Technology Capability → Adoption → Process Change → Outcome KPI → Business Impact
Model tersebut tidak berarti satu orang harus mengontrol semuanya. Sebaliknya, ia membuat batas responsibility lebih transparan. Business memiliki authority terhadap process dan outcome. Technology memiliki accountability terhadap capability dan contribution. Measurement menjaga evidence. Outcome Owner memastikan ketika gap muncul, organisasi mengambil keputusan dan tidak sekadar menambahkan feature berikutnya.
Perubahan ini penting karena software yang technically successful masih dapat menghasilkan little business impact jika process tidak berubah. Begitu pula business target dapat gagal meskipun vendor memenuhi seluruh requirement.
Business-impact-oriented development karena itu memerlukan lebih dari daftar KPI.
Ia membutuhkan orang yang benar-benar memiliki outcome tersebut.
Karena pada akhirnya, ketika system sudah go-live dan business result belum berubah, pertanyaan yang paling penting bukan:
“Siapa yang menyelesaikan fiturnya?”
Tetapi:
“Siapa yang memiliki mandat untuk memastikan bisnis benar-benar berubah—dan apa yang akan ia lakukan ketika ternyata belum?”
Discussion