Menghitung ROI Proyek Software Enterprise Sebelum Menyetujui Budget

Proposal software enterprise sering datang ke management dalam format yang sangat detail dari sisi teknologi: jumlah module, user role, integration, dashboard, mobile application, cloud infrastructure, AI capability, timeline development, hingga quotation vendor. Namun ketika pertanyaan berubah menjadi “apa dampaknya terhadap bisnis dan kapan investasi ini kembali?”, jawabannya sering jauh lebih lemah. Benefit dijelaskan dengan istilah seperti meningkatkan efisiensi, mempercepat proses, atau meningkatkan produktivitas tanpa baseline dan mekanisme pengukuran yang cukup jelas.

Padahal keputusan untuk menyetujui budget software seharusnya dibuat sebelum development dimulai, ketika sebagian besar benefit masih berupa asumsi. Pada tahap ini, management tidak membutuhkan janji ROI yang terlihat tinggi. Yang dibutuhkan adalah business case yang memperlihatkan hubungan antara problem saat ini, nilai yang sedang hilang, perubahan yang diharapkan, biaya sepanjang lifecycle, serta asumsi apa yang harus benar agar benefit benar-benar terealisasi.

PMI melalui Benefits Realization Management Framework menempatkan identifikasi expected benefits sebelum project, delivery benefits selama pelaksanaan, dan sustainment setelah project sebagai satu rangkaian. Artinya, business benefit seharusnya tidak baru dibicarakan setelah software selesai; ia perlu menjadi bagian dari investment logic sejak awal. Project Management Institute

Hal yang sama terlihat dalam GAO Cost Estimating and Assessment Guide, yang menekankan pentingnya scope, technical baseline, work breakdown structure, assumptions, data, sensitivity analysis, risk analysis, dokumentasi, dan pembaruan estimasi dengan actual cost untuk menghasilkan cost estimate yang dapat digunakan dalam planning dan budgeting. Gao

Karena itu, menghitung ROI software enterprise bukan sekadar memasukkan angka ke formula:

ROI = (Benefit – Cost) / Cost × 100%

Formula tersebut mudah. Bagian tersulit adalah memastikan Benefit dan Cost yang dimasukkan cukup realistis untuk menjadi dasar keputusan.

ROI Sebelum Project Berbeda dengan ROI Setelah Project

ROI setelah software berjalan dapat menggunakan actual evidence: berapa cycle time yang turun, berapa manual effort yang berkurang, berapa tambahan transaction capacity, atau berapa recurring cost yang berhasil dihilangkan. Sebelum budget disetujui, angka tersebut belum tersedia. Management masih menggunakan forecast.

Karena itu, ROI pra-investasi seharusnya diperlakukan sebagai investment hypothesis, bukan kepastian.

Sebuah proposal mungkin memperkirakan software dapat mengurangi processing time sebesar 50%. Namun sebelum angka tersebut menjadi benefit finansial, beberapa kondisi harus terjadi: software benar-benar selesai, user menggunakannya, process berubah, bottleneck yang diasumsikan memang merupakan root cause, volume transaction sesuai forecast, dan kapasitas yang berhasil dilepaskan dapat digunakan atau dikonversi menjadi value.

Inilah perbedaan utama antara artikel ini dengan pembahasan umum mengenai cara menghitung ROI investasi IT enterprise. Dalam konteks sebelum budget approval, pertanyaan utamanya bukan hanya berapa hasil perhitungannya, tetapi seberapa credible asumsi yang membuat angka tersebut muncul.

HM Treasury melalui The Green Book 2026 juga menekankan bahwa appraisal terhadap investasi perlu melihat objectives, alternatives, costs, benefits, risk, uncertainty, serta evidence yang mendasari forecast. Guidance tersebut secara eksplisit mengingatkan adanya optimism bias: kecenderungan memperkirakan cost terlalu rendah, benefit terlalu tinggi, dan delivery lebih cepat daripada yang akhirnya terjadi. GOV.UK

Dengan kata lain:

Pre-Investment ROI = Expected Return berdasarkan asumsi yang perlu dibuktikan.

Crocodic Pre-Investment ROI Framework

Dalam working framework Crocodic, penilaian investasi software dapat disusun melalui chain:

Business Problem → Baseline → Value at Stake → Expected Benefit → Benefit Owner → Full Lifecycle Cost → Adoption & Realization Assumption → Risk Adjustment → Scenario Analysis → ROI & Payback → Approve / Revise / Reject

Framework ini sengaja tidak dimulai dari feature atau quotation vendor.

Business Problem menjelaskan masalah yang ingin diubah. Baseline menunjukkan kondisi saat ini. Value at Stake menerjemahkan masalah tersebut menjadi nilai yang cukup material untuk diperbaiki. Expected Benefit menunjukkan perubahan yang diharapkan. Benefit Owner menentukan siapa yang bertanggung jawab memastikan benefit terjadi.

Setelah itu baru perusahaan menghitung Full Lifecycle Cost, bukan hanya development cost. Adoption & Realization Assumption menguji apakah benefit dapat benar-benar diwujudkan. Risk Adjustment mengurangi kecenderungan business case menjadi terlalu optimistis. Kemudian Scenario Analysis memperlihatkan apa yang terjadi dalam conservative, base, dan upside case.

Barulah ROI dan payback period digunakan sebagai decision metrics.

Dengan sequence ini, software tidak dimulai dari pertanyaan:

“Berapa budget yang dibutuhkan untuk membuat feature ini?”

Tetapi:

“Berapa nilai business problem yang ingin kita perbaiki dan apakah intervention ini mempunyai economic justification yang cukup?”

1. Mulai dari Baseline sebelum Menghitung Benefit

ROI tanpa baseline sangat mudah dimanipulasi karena perusahaan tidak mempunyai kondisi awal yang dapat dibandingkan.

Misalnya project bertujuan mempercepat proses invoice. Sebelum membuat projection, perusahaan perlu mengetahui kondisi saat ini: berapa invoice diproses per bulan, berapa average processing time, berapa percentage invoice yang membutuhkan rework, berapa employee yang terlibat, berapa lama invoice menunggu supporting document, dan kapan invoice akhirnya dapat dikirim ke customer.

Tanpa baseline, klaim seperti “software akan meningkatkan efisiensi 40%” hampir tidak mempunyai meaning.

Baseline juga membuat management dapat membedakan antara problem besar dan problem yang hanya terasa besar karena banyak dikeluhkan. Proses yang membutuhkan waktu satu jam tetapi hanya dilakukan sepuluh kali per bulan mungkin mempunyai value at stake yang lebih kecil dibandingkan task lima menit yang dilakukan puluhan ribu kali.

Framework sederhananya:

Current Volume × Current Effort / Delay × Business Consequence = Baseline Exposure

Baseline tidak harus selalu monetary. Cycle time, rework rate, error rate, backlog, transaction per FTE, downtime, conversion, approval time, atau percentage manual handling dapat digunakan terlebih dahulu. Monetisasi dilakukan setelah causal relationship-nya cukup jelas.

Ini juga membantu menghindari kondisi yang dibahas Crocodic dalam artikel Kenapa ROI Proyek IT Gagal di Tahun Pertama?: ketika target value tinggi tetapi tidak mempunyai measurement foundation yang cukup kuat sejak awal.

2. Hitung Value at Stake sebelum Menghitung ROI

Tidak setiap masalah layak mendapatkan software project.

Sebuah workflow dapat tidak nyaman, tetapi kalau total cost dari friction tersebut kecil dibandingkan investment yang dibutuhkan, digitalization mungkin tidak mempunyai business case yang kuat. Sebaliknya, process yang terlihat sederhana dapat menyimpan value at stake besar karena memengaruhi cash flow, high transaction volume, revenue leakage, customer retention, atau critical operational capacity.

Value at Stake adalah nilai yang secara realistis dapat dipengaruhi jika problem diperbaiki. Ini bukan benefit project secara otomatis.

Misalnya manual reconciliation menelan Rp1 miliar operational cost per tahun. Software belum tentu menghasilkan saving Rp1 miliar. Sebagian aktivitas mungkin tetap diperlukan. Sebagian cost adalah fixed payroll. Sebagian process masih membutuhkan human review.

Karena itu:

Value at Stake ≠ Expected Benefit

Value at Stake menunjukkan ukuran opportunity.

Expected Benefit adalah bagian dari opportunity tersebut yang secara realistis dapat diwujudkan oleh intervention.

Distinction ini penting karena banyak business case secara tidak sadar mengambil seluruh ukuran problem sebagai benefit project. Hasilnya ROI terlihat sangat menarik di spreadsheet tetapi sulit terealisasi setelah go-live.

3. Bedakan Empat Jenis Benefit Software

Tidak semua benefit software dapat diperlakukan sebagai financial saving yang sama.

Jenis pertama adalah Hard Cost Reduction, yaitu pengeluaran yang benar-benar dapat dihilangkan atau dikurangi. Contohnya license yang dihentikan, external processing fee yang turun, overtime yang dapat dikurangi, atau infrastructure yang dapat didecommission.

Jenis kedua adalah Capacity Release. Automation dapat membebaskan 2.000 jam kerja, tetapi jika headcount dan payroll tetap sama, perusahaan belum menghasilkan cash saving. Value-nya muncul ketika capacity tersebut digunakan untuk memproses volume lebih besar tanpa menambah FTE, mengurangi backlog, mempercepat service, atau dialihkan ke pekerjaan dengan value lebih tinggi.

Jenis ketiga adalah Revenue or Margin Impact. Software dapat mempercepat quotation, meningkatkan conversion, mengurangi stockout, menurunkan leakage, atau mempercepat billing. Benefit seperti ini dapat sangat besar, tetapi attribution-nya juga lebih sulit karena revenue biasanya dipengaruhi banyak faktor selain software.

Jenis keempat adalah Risk Reduction. Security improvement, compliance system, disaster recovery, audit automation, atau modernization dapat mengurangi probability dan impact dari incident. Benefit-nya bukan revenue baru, melainkan pengurangan expected loss.

Karena itu, business case sebaiknya tidak mencampur semuanya menjadi satu angka tanpa penjelasan.

Crocodic menggunakan klasifikasi sederhana:

Cost Saving → Capacity Gain → Revenue / Margin Impact → Risk Reduction

Masing-masing membutuhkan evidence yang berbeda.

4. Jangan Menganggap “Jam Dihemat” Sama dengan Profit

Salah satu pola ROI software yang paling umum adalah:

Jumlah jam yang dihemat × hourly salary = financial saving

Perhitungan tersebut dapat berguna sebagai starting point, tetapi tidak selalu berarti actual return.

Misalnya automation menghemat 5.000 jam per tahun. Jika employee tetap bekerja dengan jumlah dan payroll yang sama, perusahaan belum otomatis memperoleh cash saving sebesar nilai seluruh jam tersebut.

Benefit-nya mungkin berupa capacity avoidance: ketika volume naik, perusahaan tidak perlu merekrut lima orang baru. Bisa juga berupa faster customer response, shorter financial closing, atau kemampuan team mengerjakan aktivitas yang sebelumnya tertunda.

Karena itu, business case perlu menjelaskan conversion mechanism:

Time Saved → Capacity Released → Operational Change → Financial / Business Benefit

Tanpa mekanisme tersebut, “productivity saving” berisiko menjadi angka teoretis.

Hal ini sangat relevan dengan business-impact orientation. Software tidak menghasilkan value karena employee mengklik lebih sedikit tombol. Value terjadi ketika perubahan tersebut menghasilkan outcome yang mempunyai consequence terhadap operation atau financial performance.

5. Hitung Full Lifecycle Cost, Bukan Harga Development

ROI dapat terlihat sangat tinggi jika denominator-nya hanya quotation awal.

Padahal enterprise software mempunyai biaya sebelum, selama, dan setelah go-live. Discovery, architecture, development, integration, migration, testing, training, infrastructure, license, security, change management, maintenance, support, enhancement, serta eventual modernization dapat menjadi bagian dari lifecycle cost.

GAO Cost Estimating Guide menekankan pentingnya cost estimate yang mempunyai defined scope, technical baseline, assumptions, risk analysis, dan lifecycle perspective agar budget decision tidak hanya menggunakan sebagian cost yang paling mudah terlihat. Gao

Crocodic juga telah membahas hal ini melalui Biaya Sistem Enterprise: Cara Menyusun Budget yang Realistis dan Budget Software Enterprise: New Build vs Repeat Investment.

Untuk pre-investment ROI, gunakan:

Total Investment Cost = Initial Project Cost + Implementation Cost + Recurring Run Cost + Change / Maintenance Cost + Risk Allowance

Horizon yang dipilih dapat tiga, lima, atau periode lain yang sesuai lifecycle keputusan. Yang terpenting adalah benefit dan cost dihitung pada periode yang sama.

6. Masukkan Adoption ke Dalam Model ROI

Software yang tidak digunakan tidak menghasilkan benefit sesuai business case.

Hal ini terdengar sederhana, tetapi banyak proposal secara implisit menggunakan assumption 100% benefit realization. Misalnya automation diproyeksikan menghemat Rp1 miliar per tahun, lalu Rp1 miliar langsung dimasukkan sebagai annual benefit sejak tahun pertama.

Padahal realisasi dapat bertahap.

Bulan awal masih ada parallel process. Sebagian user belum berpindah. Beberapa exception belum dapat ditangani. Volume transaksi yang masuk system baru mungkin belum mencapai 100%. Data quality juga dapat membutuhkan stabilization.

Karena itu, Crocodic menggunakan konsep:

Realized Benefit = Maximum Potential Benefit × Adoption Rate × Process Effectiveness × Realization Factor

Ini bukan standar accounting, melainkan working model untuk memaksa business case menjelaskan asumsi.

Misalnya maximum opportunity Rp1 miliar per tahun. Jika hanya 80% transaction menggunakan process baru dan intervention hanya mampu menghilangkan 75% friction, expected realized benefit secara konseptual sudah berbeda jauh dari Rp1 miliar.

Business case yang credible tidak perlu membuat angka tampak setinggi mungkin.

Ia perlu menunjukkan apa yang harus terjadi agar benefit tercapai.

7. Tetapkan Benefit Owner sebelum Budget Disetujui

ROI sering dianggap tanggung jawab Finance atau IT. Padahal technology team tidak selalu mempunyai control terhadap business behavior setelah go-live.

Jika project bertujuan menurunkan invoice lead time, Finance atau operation perlu memiliki outcome tersebut. Jika targetnya meningkatkan sales conversion, sales leadership perlu menjadi benefit owner. Jika objective-nya menurunkan equipment downtime, maintenance operation perlu bertanggung jawab terhadap realized outcome.

PMI menekankan bahwa benefit perlu diidentifikasi dan selaras dengan strategy, kemudian dipantau hingga transition ke operational atau business owner agar value dapat dipertahankan setelah project berakhir. Project Management Institute

Karena itu, proposal sebelum budget approval idealnya mencantumkan:

Benefit → Baseline → Target → Measurement Method → Benefit Owner → Measurement Date

Contohnya:

Angka pada tabel di atas hanya ilustrasi. Business case nyata harus menggunakan baseline dari operation perusahaan.

Perubahan kecil ini membuat proposal software jauh lebih accountable. Ketika software selesai, organization tahu siapa yang harus memastikan benefit tidak berhenti pada feature delivery.

8. Gunakan Conservative, Base, dan Upside Scenario

Satu angka ROI memberikan impression presisi yang sering tidak nyata.

Sebelum project dimulai, management belum mengetahui secara pasti development cost akhir, adoption speed, integration complexity, actual benefit, atau perubahan business volume. Karena itu, lebih sehat menggunakan scenario.

Conservative Case menggunakan adoption lebih rendah, benefit lebih lambat, atau cost lebih tinggi.

Base Case menggunakan assumption yang dianggap paling probable berdasarkan evidence saat ini.

Upside Case menggambarkan kondisi ketika adoption dan benefit realization berjalan lebih baik.

Pendekatan ini sejalan dengan prinsip appraisal dalam Green Book yang meminta decision maker mempertimbangkan risk, uncertainty, sensitivity, dan kemungkinan actual costs maupun benefits berbeda dari forecast. Guidance tersebut juga meminta appraisal mengoreksi optimism bias, bukan memperlakukan base forecast sebagai certainty. GOV.UK

Sebagai illustration:

Angka tersebut bukan benchmark pasar maupun benchmark Crocodic. Tabel hanya menunjukkan bagaimana satu project dapat menghasilkan investment conclusion berbeda ketika asumsi benefit berubah.

Jika sebuah project hanya terlihat menarik pada upside case, approval risk-nya jauh berbeda dibandingkan project yang masih menghasilkan positive return pada conservative case.

9. Tambahkan Payback Period, Jangan Hanya ROI

Dua project dapat mempunyai ROI lima tahun yang sama tetapi cash-flow profile sangat berbeda.

Project A menghasilkan benefit besar sejak tahun pertama.

Project B baru memberikan benefit pada tahun keempat setelah implementation yang panjang.

Bagi management, timing tersebut penting karena capital terkunci lebih lama pada Project B.

Karena itu, selain ROI gunakan Payback Period:

Payback Period = Waktu yang dibutuhkan sampai cumulative benefit menutup cumulative investment

Untuk investasi dengan horizon yang lebih panjang atau cash flow yang material antar-tahun, management juga dapat menggunakan NPV atau discounted cash-flow analysis bersama Finance. The Green Book menggunakan discounting dalam appraisal karena benefit dan cost yang terjadi pada waktu berbeda tidak mempunyai value yang identik hari ini. GOV.UK

Artikel ini tidak bermaksud menggantikan financial-modeling standard perusahaan. Principle yang penting adalah:

Return magnitude dan return timing perlu dinilai bersama.

ROI tinggi yang baru terjadi sangat lama dapat mempunyai attractiveness berbeda dari ROI lebih rendah tetapi memberikan benefit lebih cepat dan lebih predictable.

10. Bandingkan dengan Cost of Doing Nothing

Business case sering membandingkan invest dengan tidak mengeluarkan uang.

Padahal “tidak melakukan project” belum tentu berarti zero cost.

Jika existing system menyebabkan reconciliation manual Rp500 juta per tahun, menunda project satu tahun berarti company tetap membayar friction tersebut. Jika legacy system mengalami rising maintenance cost, delay mempunyai economic consequence. Jika current process membatasi transaction capacity, opportunity juga dapat hilang.

Karena itu, decision seharusnya membandingkan setidaknya:

Invest Now vs Delay vs Do Nothing vs Alternative Solution

Artikel Crocodic tentang Cost of Doing Nothing pada modernisasi legacy system menjelaskan perspective ini secara lebih spesifik pada modernization.

Namun Cost of Doing Nothing juga tidak boleh digunakan untuk membesar-besarkan ROI. Hanya consequence yang mempunyai causal relationship dan evidence memadai yang layak dimasukkan.

Misalnya maintenance system existing Rp300 juta per tahun dan benar-benar dapat dihentikan setelah migration, angka tersebut dapat menjadi avoidable cost. Tetapi potensi “kehilangan revenue miliaran” tanpa historical evidence atau causal model yang jelas sebaiknya dipisahkan sebagai strategic benefit, bukan dimasukkan seolah-olah cash return pasti.

11. Risk-Adjust Benefit, Bukan Hanya Menambahkan Contingency Cost

Project risk biasanya diterjemahkan menjadi contingency pada budget.

Misalnya quotation Rp2 miliar ditambah contingency 10%. Pendekatan tersebut membantu dari sisi cost, tetapi masih menyisakan masalah: benefit sering tetap dihitung 100%.

Padahal benefit juga mempunyai uncertainty.

System mungkin terlambat go-live sehingga benefit tahun pertama lebih kecil. Adoption dapat lebih rendah. Process mungkin tidak berubah sebesar asumsi awal. Integration dapat membatasi coverage automation. Business volume dapat berubah.

The Green Book menekankan bahwa optimism bias dapat memengaruhi capital cost, operating cost, project duration, dan benefit realization. Appraisal yang lebih prudent perlu mengakui kemungkinan cost naik sekaligus benefit turun. GOV.UK

Karena itu, Crocodic menggunakan:

Expected Benefit → Confidence Level → Risk-Adjusted Benefit

Benefit yang didukung historical transaction data dan proven automation mungkin mempunyai confidence lebih tinggi.

Benefit yang bergantung pada perubahan customer behavior atau revenue uplift dapat mempunyai confidence lebih rendah.

Ini membuat management dapat membedakan:

High Benefit, High Confidence

dengan

High Benefit, Low Confidence

Keduanya tidak seharusnya diperlakukan sama saat budget approval.

12. Contoh Sederhana Pre-Investment ROI

Bayangkan perusahaan ingin membangun software untuk mengotomasi proses order-to-invoice.

Hasil assessment awal menunjukkan terdapat manual reconciliation, duplicate input, dan delay sebelum invoice dapat diterbitkan. Setelah baseline dibuat, team memperkirakan potential measurable benefit sebesar Rp1,2 miliar per tahun dari gabungan cost avoidance, recovered capacity yang benar-benar dapat dikonversi, serta reduction pada specific operational leakage.

Initial project membutuhkan Rp1,5 miliar. Recurring maintenance dan infrastructure diperkirakan Rp200 juta per tahun. Horizon business case tiga tahun.

Jika seluruh potential benefit langsung dianggap 100%, proposal akan terlihat sangat menarik. Namun management kemudian menggunakan realization assumptions:

Tahun pertama, hanya 50% benefit terealisasi karena rollout dan adoption.

Tahun kedua, 80%.

Tahun ketiga, 90%.

Perhitungannya menjadi:

Year 1 Benefit = Rp600 juta

Year 2 Benefit = Rp960 juta

Year 3 Benefit = Rp1,08 miliar

Total gross benefit = Rp2,64 miliar

Total lifecycle cost = initial Rp1,5 miliar + recurring Rp600 juta = Rp2,1 miliar

Net benefit = Rp540 juta

ROI ilustratif:

Rp540 juta / Rp2,1 miliar × 100% ≈ 25,7%

Sekali lagi, ini hanya simulasi untuk menjelaskan method, bukan benchmark proyek enterprise.

Yang membuat model ini lebih berguna bukan angka 25,7%-nya. Yang penting adalah management sekarang dapat menguji assumption: apakah potential benefit Rp1,2 miliar valid? Apakah 50% adoption tahun pertama masuk akal? Apakah maintenance Rp200 juta sudah mencakup seluruh recurring cost? Bagaimana jika integration lebih mahal? Bagaimana jika realization hanya 60%?

Dengan demikian, ROI berubah dari jawaban menjadi alat untuk menguji business case.

Jangan Approve Project Hanya karena ROI Positif

ROI positif belum otomatis berarti project layak menjadi priority.

Perusahaan mempunyai capital dan engineering capacity yang terbatas. Project dengan ROI 20% dapat kalah prioritas dengan project lain yang ROI-nya 50%, payback lebih cepat, strategic fit lebih tinggi, dan execution risk lebih rendah.

Sebaliknya, project dengan ROI finansial rendah masih dapat layak dilakukan jika memenuhi mandatory compliance, cybersecurity requirement, critical resilience, atau strategic capability yang sulit dimonetisasi.

Karena itu, investment decision sebaiknya melihat beberapa layer:

Financial Return

Strategic Impact

Risk Reduction

Time-to-Value

Execution Feasibility

Opportunity Cost

Capability Created

HM Treasury juga menggunakan appraisal yang lebih luas daripada satu financial metric: objectives, monetisable dan non-monetisable benefits, financial impact, risk, uncertainty, dan alternatives perlu dipertimbangkan untuk membuat value-for-money decision. GOV.UK

Dalam enterprise, ROI adalah salah satu evidence. Bukan satu-satunya decision criterion.

Crocodic ROI Readiness Checklist sebelum Budget Approval

Sebelum project software mendapat final approval, management setidaknya perlu mampu menjawab pertanyaan berikut.

Apakah business problem mempunyai baseline yang dapat diverifikasi?

Apakah value at stake cukup material dibandingkan investment?

Apakah benefit mempunyai causal relationship dengan software yang akan dibangun?

Apakah capacity saving benar-benar dapat dikonversi menjadi value?

Apakah revenue benefit mempunyai attribution yang cukup masuk akal?

Apakah lifecycle cost sudah mencakup implementation, operation, maintenance, dan change?

Siapa benefit owner setelah software go-live?

Berapa adoption yang dibutuhkan agar target tercapai?

Apa conservative scenario jika cost naik atau benefit turun?

Berapa payback period-nya?

Apa Cost of Doing Nothing atau alternative solution?

Jika pertanyaan tersebut belum dapat dijawab, business case belum tentu harus ditolak. Namun project mungkin perlu kembali ke discovery atau assessment sebelum budget besar dikunci.

Crocodic Perspective: Budget Harus Mengikuti Business Impact Hypothesis

Dalam perspective Crocodic, proposal software seharusnya mempunyai traceability dari budget menuju business impact.

Framework lengkapnya:

Business Problem → Baseline → Value at Stake → Expected Benefit → Benefit Owner → Required Capability → Technology Intervention → Full Lifecycle Cost → Adoption Assumption → Risk Adjustment → Scenario → ROI / Payback → Approval → Post-Go-Live Measurement

Ini berbeda dengan model:

Feature List → Estimasi Mandays → Harga → Approval

Feature list tetap dibutuhkan untuk delivery. Namun feature bukan alasan investasi.

Alasan investasinya adalah perubahan business outcome yang ingin dicapai.

Karena itu, business case perlu memiliki Impact Hypothesis:

Jika [technology intervention] memperbaiki [root cause], maka [business metric] seharusnya bergerak dari [baseline] menuju [target], karena [causal relationship].

Contohnya:

Jika reconciliation order-delivery-invoice diotomasi dan data dapat divalidasi sebelum billing, maka invoice cycle time seharusnya turun dari baseline menuju target karena manual matching dan repeat verification berkurang.

Hipotesis tersebut kemudian dapat diuji setelah go-live.

Jika KPI bergerak, organization memperoleh evidence bahwa investment logic benar.

Jika tidak bergerak, perusahaan dapat melakukan diagnosis sebelum menambah feature atau budget baru.

Pendekatan ini juga membantu mencegah problem yang dibahas dalam Business Impact Gap: software selesai tetapi KPI tetap tidak bergerak.

Approve, Revise, atau Reject

Hasil ROI analysis tidak selalu harus menghasilkan keputusan ya atau tidak.

Crocodic melihat tiga kemungkinan:

Approve ketika problem cukup material, causal relationship jelas, cost cukup complete, benefit mempunyai confidence yang reasonable, dan scenario menunjukkan investment layak.

Revise ketika business problem valid tetapi scope, cost, benefit assumption, atau intervention masih perlu diubah. Project dapat diperkecil, dilakukan bertahap, dimulai dari satu high-value process, atau dilakukan discovery lebih dahulu.

Reject / Defer ketika value at stake terlalu kecil, root cause tidak membutuhkan software, economics tidak masuk, dependency belum siap, atau alternatif lain memberikan impact lebih tinggi dengan investment lebih rendah.

Keputusan tidak membangun software juga dapat menjadi hasil assessment yang baik.

Business-impact orientation bukan berarti selalu menemukan justification untuk development.

Tujuannya adalah memastikan technology budget diarahkan pada problem yang memang cukup bernilai untuk diselesaikan.

Kesimpulan

Menghitung ROI proyek software enterprise sebelum budget disetujui bukan latihan untuk menghasilkan angka return setinggi mungkin.

Tujuannya adalah menguji apakah investment hypothesis cukup kuat.

Formula ROI tetap sederhana:

ROI = (Total Benefit – Total Cost) / Total Cost × 100%

Namun angka yang dapat dipercaya membutuhkan proses yang lebih panjang:

Business Problem → Baseline → Value at Stake → Expected Benefit → Benefit Owner → Full Lifecycle Cost → Adoption & Realization Assumption → Risk Adjustment → Scenario Analysis → ROI & Payback

Baseline mencegah improvement dihitung dari asumsi. Value at Stake memastikan problem cukup material. Benefit classification mencegah time saving otomatis dianggap cash saving. Lifecycle cost menghindari budget hanya melihat development. Adoption dan benefit ownership memperlihatkan bagaimana value akan benar-benar direalisasikan. Risk adjustment dan scenario analysis mengurangi optimism bias.

Prinsip ini konsisten dengan GAO Cost Estimating and Assessment Guide yang menekankan reliable cost estimation dan risk analysis, PMI Benefits Realization Management yang menghubungkan investment dengan expected dan realized benefits, serta The Green Book 2026 yang menekankan costs, benefits, alternatives, uncertainty, dan optimism bias dalam investment appraisal.

Pada akhirnya, pertanyaan management sebelum menandatangani budget software seharusnya bukan hanya:

“Berapa biaya project ini?”

Tetapi:

“Business value apa yang secara realistis dapat tercipta, asumsi apa yang harus benar agar value tersebut terealisasi, dan apakah return-nya masih layak ketika kita menggunakan scenario yang lebih konservatif?”

Jika jawabannya jelas, ROI menjadi alat decision-making.

Jika jawabannya belum jelas, menghitung persentase ROI lebih presisi tidak akan membuat business case menjadi lebih kuat.