{"id":14678,"date":"2026-09-07T16:15:47","date_gmt":"2026-09-07T09:15:47","guid":{"rendered":"https:\/\/crocodic.com\/?p=14678"},"modified":"2026-09-07T16:15:48","modified_gmt":"2026-09-07T09:15:48","slug":"budget-software-enterprise-new-build-vs-repeat-investment-bagaimana-menyusun-anggaran-sistem-jangka-panjang","status":"publish","type":"post","link":"https:\/\/crocodic.com\/en\/budget-software-enterprise-new-build-vs-repeat-investment-bagaimana-menyusun-anggaran-sistem-jangka-panjang\/","title":{"rendered":"Budget Software Enterprise: New Build vs Repeat Investment, Bagaimana Menyusun Anggaran Sistem Jangka Panjang?"},"content":{"rendered":"

Ketika perusahaan menyusun budget software enterprise, angka yang paling mudah terlihat hampir selalu adalah biaya implementasi awal. Proposal pengembangan software mencantumkan nilai project, timeline, scope, dan milestone pembayaran; management kemudian menggunakan angka tersebut sebagai dasar approval. Pendekatan ini masuk akal untuk memutuskan apakah sebuah project dapat dimulai, tetapi tidak cukup untuk menjawab pertanyaan yang lebih penting: berapa investment yang sebenarnya diperlukan agar sistem tetap relevan, reliable, dan dapat mengikuti perubahan bisnis selama tiga sampai lima tahun setelah go-live?<\/strong> Software enterprise tidak berhenti membutuhkan investasi ketika project dinyatakan selesai. Setelah digunakan secara nyata, business rules berubah, volume transaksi meningkat, application lain perlu diintegrasikan, security requirement berkembang, user menemukan workflow baru, dan architecture yang sebelumnya cukup dapat mulai membatasi perubahan berikutnya.<\/p>\n\n\n\n

Microsoft menggambarkan application modernization sebagai continuous lifecycle<\/strong>, bukan one-time project. Assessment, planning, execution, expansion, innovation, dan optimization berjalan secara berulang agar application tetap relevan terhadap perubahan technology maupun operation. (Microsoft Learn<\/a>) Prinsip ini memberikan implikasi langsung terhadap budgeting: perusahaan sebaiknya tidak melihat software hanya sebagai initial capital commitment menuju go-live, tetapi sebagai business capability yang mempunyai lifecycle investment<\/strong>.<\/p>\n\n\n\n

Karena itu, budget software enterprise sebaiknya membedakan dua jenis investment yang mempunyai karakter berbeda. New build investment membeli capability baru<\/strong>, sedangkan repeat investment mempertahankan kemampuan capability tersebut untuk terus berubah<\/strong>. Initial build biasanya mempunyai ticket size lebih besar karena perusahaan membiayai discovery, architecture, core workflow, data model, user experience, integration foundation, testing, deployment, dan operating baseline. Setelah sistem berjalan, nominal setiap perubahan mungkin terlihat lebih kecil, tetapi investment terjadi jauh lebih sering dalam bentuk enhancement, maintenance, integration, infrastructure, security improvement, additional module, dan modernization.<\/p>\n\n\n\n

Go-live bukan akhir investasi software. Go-live mengubah jenis investasi: dari membangun capability baru menjadi mempertahankan kemampuan sistem untuk ikut berubah bersama bisnis.<\/strong><\/p>\n\n\n\n

Distinction ini penting karena perusahaan dapat membuat keputusan budget yang salah ketika seluruh perhatian diberikan kepada development cost tahun pertama. Proposal yang paling murah belum tentu menghasilkan lifecycle economics terbaik, sementara software yang membutuhkan repeat investment juga tidak otomatis berarti implementasinya buruk. Sistem yang digunakan untuk operasi nyata memang harus berevolusi. Pertanyaan management bukan bagaimana membuat repeat investment menjadi nol, tetapi bagaimana memastikan setiap investment setelah go-live mempunyai hubungan yang jelas dengan business value, reliability, risk reduction, atau kemampuan perusahaan berubah lebih cepat<\/strong>.<\/p>\n\n\n\n

Mengapa Budget Software Tidak Berhenti di Biaya Implementasi?<\/strong><\/h2>\n\n\n\n

Software berbeda dari asset yang fungsinya relatif tetap setelah dibeli. Sistem procurement yang diluncurkan hari ini mungkin mempunyai approval rule berdasarkan struktur organisasi sekarang, tetapi tahun depan perusahaan membuka business unit baru. ERP yang saat ini cukup untuk 500 pengguna dapat menghadapi volume jauh lebih tinggi dua tahun berikutnya. CRM perlu diintegrasikan dengan customer platform baru, regulator dapat menuntut control tambahan, atau perusahaan mulai menggunakan AI pada workflow yang sebelumnya sepenuhnya manual. Sistem yang tidak berubah ketika lingkungan bisnis berubah akhirnya memaksa bisnis membuat workaround di luar sistem.<\/p>\n\n\n\n

Microsoft menempatkan modernization sebagai continuum untuk mempertahankan scalability, agility, security, compliance, dan business relevance. (Microsoft Learn<\/a>) AWS menggunakan prinsip serupa dari sisi economics: cost optimization bukan sekadar memotong pengeluaran, tetapi menjalankan technology agar menghasilkan business value pada economics yang efektif serta mengukur value dari investment optimization tersebut. (Dokumen AWS<\/a>) Ini berarti budget software perlu mempunyai ruang bukan hanya untuk \u201cmenjalankan server\u201d, tetapi juga untuk menjaga system capability agar tidak tertinggal dari kebutuhan perusahaan.<\/p>\n\n\n\n

Masalah muncul ketika perusahaan hanya mempunyai dua kategori budget: project baru<\/strong> dan maintenance<\/strong>. Hampir seluruh investment setelah go-live kemudian dimasukkan ke maintenance, padahal sifatnya sangat berbeda. Memperbaiki bug production berbeda dengan menambahkan integration ERP\u2013CRM. Patch security berbeda dengan membangun capability baru untuk satu business unit. Refactoring architecture agar perubahan berikutnya lebih murah juga berbeda dengan monthly infrastructure cost. Jika semuanya disebut maintenance, management kehilangan visibility mengenai mengapa uang terus dikeluarkan dan apa yang sebenarnya dibeli oleh pengeluaran tersebut<\/strong>.<\/p>\n\n\n\n

Karena itu Crocodic menggunakan pendekatan lifecycle budget yang memisahkan software investment berdasarkan tujuan bisnisnya, bukan sekadar berdasarkan nama invoice vendor.<\/p>\n\n\n\n

Crocodic Software Investment Lifecycle<\/strong><\/h1>\n\n\n\n

Framework awal yang dapat digunakan adalah:<\/p>\n\n\n\n

Software Lifecycle Investment = Create + Evolve + Operate + Protect + Modernize<\/strong><\/p>\n\n\n\n

Lima bucket tersebut tidak dimaksudkan sebagai standar accounting. Finance tetap perlu menentukan treatment CapEx, OpEx, capitalization, depreciation, maupun aturan internal perusahaan sesuai accounting policy yang berlaku. Framework ini digunakan sebagai management planning model<\/strong>, agar CEO, CFO, CIO, dan Head of IT dapat melihat ke mana software investment diarahkan dan risiko apa yang muncul apabila salah satu bagian tidak disediakan.<\/p>\n\n\n\n

Investment Bucket<\/strong><\/td>Tujuan<\/strong><\/td>Contoh<\/strong><\/td><\/tr>
Create<\/strong><\/td>Membangun capability baru<\/td>discovery, core system, module baru, implementation<\/td><\/tr>
Evolve<\/strong><\/td>Mengikuti perubahan bisnis<\/td>enhancement, workflow changes, integration, feature expansion<\/td><\/tr>
Operate<\/strong><\/td>Menjaga layanan tetap berjalan<\/td>infrastructure, monitoring, support, backup, routine maintenance<\/td><\/tr>
Protect<\/strong><\/td>Mengendalikan risiko<\/td>security, compliance, access control, recovery, dependency update<\/td><\/tr>
Modernize<\/strong><\/td>Menurunkan cost of change masa depan<\/td>refactor, API enablement, re-architecture, migration, performance improvement<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Keuntungan menggunakan bucket semacam ini adalah management tidak lagi melihat seluruh pengeluaran setelah launch sebagai \u201cbiaya tambahan\u201d. Sebagian memang operational expense untuk mempertahankan reliability. Sebagian adalah growth investment karena menghasilkan business capability baru. Sebagian lain adalah risk reduction dan modernization investment yang tidak selalu menghasilkan feature visible tetapi mencegah architecture menjadi semakin mahal untuk dikembangkan.<\/p>\n\n\n\n

1. Create: Initial Build Membeli Fondasi Business Capability<\/strong><\/h2>\n\n\n\n

New build merupakan investasi yang paling mudah dimasukkan ke business case karena scope dan outcome biasanya terlihat jelas. Perusahaan membutuhkan procurement platform, warehouse system, sales application, customer portal, custom ERP module, atau operational system baru; vendor melakukan discovery, menyusun architecture, membangun application, melakukan testing, lalu deployment.<\/p>\n\n\n\n

Namun biaya implementation tidak seharusnya hanya dinilai dari jumlah feature. Artikel Crocodic mengenai cara membandingkan quotation custom software<\/a> menekankan bahwa dua proposal dengan daftar fitur terlihat sama dapat mempunyai commitment berbeda pada integration, data migration, testing, ownership, support, security, dan change mechanism. (Crocodic<\/a>) Karena itu initial budget harus menjawab bukan hanya \u201cberapa harga membuat sistem?\u201d<\/strong>, tetapi \u201cfoundation apa yang sudah termasuk agar sistem layak menjadi business asset setelah go-live?\u201d<\/strong><\/p>\n\n\n\n

Create budget umumnya dapat meliputi discovery dan process analysis, solution architecture, data model, core workflow, UX, integration foundation, data migration, testing, security baseline, deployment, documentation, training, serta transition menuju operation. Scope sebenarnya akan berbeda pada setiap project, tetapi principle-nya sama: initial build membiayai baseline capability<\/strong> yang membuat proses bisnis dapat berjalan secara nyata, bukan hanya menghasilkan feature list.<\/p>\n\n\n\n

Ini juga menjelaskan mengapa memilih quotation termurah tanpa normalisasi scope dapat membuat repeat investment terlihat lebih besar di kemudian hari. Integration yang tidak dibangun pada fase awal tetap perlu dibangun ketika operation mulai bergantung padanya. Security yang hanya dipikirkan sesudah go-live menjadi remediation. Data model yang tidak mengantisipasi critical relationship dapat menghasilkan refactoring. Initial savings dapat sekadar memindahkan pengeluaran dari Create ke Evolve atau Modernize beberapa bulan kemudian.<\/p>\n\n\n\n

2. Evolve: Repeat Investment Membeli Kemampuan Sistem Mengikuti Bisnis<\/strong><\/h2>\n\n\n\n

Setelah sistem digunakan, business mulai menemukan kondisi yang tidak sepenuhnya terlihat saat requirement awal dibuat. Approval bertambah, proses berubah, produk baru diluncurkan, department baru muncul, customer expectation berubah, atau perusahaan membutuhkan reporting dan automation tambahan. Ini bukan selalu scope failure. Dalam enterprise system yang hidup cukup lama, perubahan merupakan kondisi normal.<\/p>\n\n\n\n

Evolve budget membiayai adaptation tersebut. Contohnya termasuk additional workflow, integration dengan application baru, enhancement terhadap existing module, additional dashboard, change pada approval matrix, support untuk business unit baru, automation, dan capability lain yang muncul karena company berkembang. Investment jenis ini sebaiknya dihubungkan dengan change roadmap, bukan diperlakukan seperti bug fixing.<\/p>\n\n\n\n

Di sinilah custom enterprise software mempunyai economics yang menarik tetapi juga harus dikelola secara sadar. Sistem custom memberi perusahaan fleksibilitas untuk menyesuaikan workflow terhadap cara kerja bisnis. Crocodic sendiri memosisikan Custom Enterprise Software<\/a> sebagai system yang dibentuk mengikuti proses perusahaan dan dapat dikembangkan secara iteratif ketika requirement berkembang. (Crocodic<\/a>) Fleksibilitas tersebut mempunyai value ketika enhancement menghasilkan kemampuan baru dengan cost of change yang tetap terkendali.<\/p>\n\n\n\n

Repeat investment bukan otomatis tanda software gagal. Repeat investment menjadi masalah ketika perusahaan terus membayar perubahan kecil dengan effort besar karena architecture tidak lagi mendukung perubahan secara ekonomis.<\/strong><\/p>\n\n\n\n

Management karena itu perlu membedakan healthy evolution<\/strong> dengan structural friction<\/strong>. Healthy evolution berarti company menambahkan capability karena bisnis berkembang. Structural friction berarti banyak budget habis hanya untuk mengatasi limitation system, duplicated logic, fragile code, atau integration yang terus rusak.<\/p>\n\n\n\n

3. Operate: Software yang Sudah Go-Live Tetap Memiliki Run Cost<\/strong><\/h2>\n\n\n\n

Sistem enterprise yang telah production membutuhkan operation agar reliability tetap terjaga. Infrastructure, cloud resources, database, monitoring, backup, domain, certificates, third-party services, support, observability, incident handling, routine updates, dan operational tooling merupakan contoh biaya yang dapat terus muncul.<\/p>\n\n\n\n

AWS Cost Optimization Pillar bahkan menekankan perlunya ownership, budgeting, forecasting, monitoring expenditure, dan review workload secara berkala karena technology cost harus dikelola sepanjang operation, bukan hanya saat infrastructure pertama kali dipilih. (Dokumen AWS<\/a>) Prinsip tersebut dapat diterapkan lebih luas pada software portfolio: system operation membutuhkan planned budget agar company tidak hanya mengeluarkan biaya ketika incident sudah terjadi.<\/p>\n\n\n\n

Planned operation juga perlu dibedakan dari unplanned remediation. Membayar monitoring dan backup merupakan investment untuk menjaga service health. Menghabiskan banyak engineering hours setiap bulan karena application terus mengalami incident yang sama menunjukkan problem berbeda. Jika unplanned work terus meningkat, management sebaiknya tidak sekadar menambah maintenance budget; penyebab architecture perlu dianalisis.<\/p>\n\n\n\n

Karena itu salah satu metric yang berguna bukan hanya total maintenance cost<\/strong>, tetapi proporsi budget yang digunakan untuk planned operation dibanding firefighting. Sistem yang terlihat murah secara license atau hosting dapat menjadi mahal apabila tim IT terus-menerus menghabiskan waktu untuk troubleshooting dan reconciliation.<\/p>\n\n\n\n

4. Protect: Security dan Risk Tidak Boleh Menunggu Incident<\/strong><\/h2>\n\n\n\n

Security investment sering sulit terlihat value-nya karena hasil terbaik adalah sesuatu yang tidak terjadi: tidak ada unauthorized access, tidak ada data loss, tidak ada prolonged downtime, dan tidak ada major compliance failure. Akibatnya Protect budget dapat kalah prioritas dibanding feature yang terlihat langsung oleh business user.<\/p>\n\n\n\n

Padahal semakin lama sebuah system digunakan, semakin banyak dependency yang berubah. Library memasuki end-of-support, authentication standard berkembang, data access meningkat, third-party integration bertambah, dan volume informasi sensitif dapat membesar. Protection investment dapat mencakup vulnerability remediation, access control improvement, dependency upgrade, penetration testing follow-up, backup and recovery improvement, security monitoring, audit trail, atau compliance changes.<\/p>\n\n\n\n

Budget ini perlu dipisahkan dari feature development karena decision logic-nya berbeda. Feature dapat diprioritaskan berdasarkan revenue atau productivity. Security improvement diprioritaskan berdasarkan risk exposure \u00d7 consequence \u00d7 likelihood<\/strong>. Menggabungkan keduanya ke satu backlog sering membuat security terus kalah oleh request business yang lebih visible.<\/p>\n\n\n\n

Protect juga menjaga repeat investment tidak berubah menjadi emergency spending. Security remediation setelah incident biasanya mempunyai economics jauh lebih buruk daripada planned improvement karena perusahaan membayar recovery, disruption, engineering time, investigation, dan reputational consequence secara bersamaan.<\/p>\n\n\n\n

5. Modernize: Membayar Sekarang untuk Menurunkan Cost of Change Berikutnya<\/strong><\/h2>\n\n\n\n

Modernization merupakan investment yang paling sering sulit dijelaskan kepada non-technical stakeholder karena output-nya tidak selalu berupa feature baru. Tim dapat melakukan refactoring, memperbaiki API architecture, memisahkan module, meningkatkan observability, mengganti unsupported dependency, memperbaiki performance, atau memigrasikan bagian infrastructure. Dari perspektif user, screen yang digunakan hari ini mungkin terlihat sama.<\/p>\n\n\n\n

Namun business value modernization muncul pada future changeability<\/strong>. Microsoft menjelaskan modernization sebagai lifecycle yang meningkatkan agility dan membantu organisasi merespons demand lebih cepat; assessment bahkan digunakan untuk mengidentifikasi technical debt, inefficiency, security exposure, dan bagian portfolio yang perlu dioptimalkan. (Microsoft Learn<\/a>) Jika modernization berhasil menurunkan lead time perubahan dari delapan minggu menjadi tiga minggu, value-nya bukan pada refactoring itu sendiri tetapi pada business capability yang dapat dirilis lebih cepat setelahnya.<\/p>\n\n\n\n

Artikel Crocodic mengenai Cost of Doing Nothing pada legacy system<\/a> juga membahas bahwa tidak melakukan modernization bukan berarti biaya menjadi nol. Expense dapat berpindah ke maintenance, incident, manual work, integration workaround, risk, cost of change, dan opportunity yang tertunda. (Crocodic<\/a>) Oleh karena itu Modernize budget tidak seharusnya dibandingkan dengan baseline \u201ctidak keluar uang\u201d, tetapi terhadap future cost dari architecture existing<\/strong>.<\/p>\n\n\n\n

Modernization membeli sesuatu yang jarang terlihat dalam feature list: biaya perubahan yang lebih rendah untuk keputusan bisnis berikutnya.<\/strong><\/p>\n\n\n\n

New Build vs Repeat Investment: Apa yang Sebenarnya Dibeli?<\/strong><\/h2>\n\n\n\n

Perbedaan fundamental keduanya dapat dilihat dari economics-nya.<\/p>\n\n\n\n

New Build Investment<\/strong><\/td>Repeat Investment<\/strong><\/td><\/tr>
Membeli capability baru<\/td>Menjaga capability tetap relevan<\/td><\/tr>
Commitment besar di awal<\/td>Lebih kecil tetapi berulang<\/td><\/tr>
Business case berbasis project<\/td>Business case berbasis lifecycle<\/td><\/tr>
Scope relatif didefinisikan<\/td>Demand berkembang seiring operation<\/td><\/tr>
Fokus menuju go-live<\/td>Fokus adaptability setelah go-live<\/td><\/tr>
Risiko utama delivery<\/td>Risiko utama cost of change & sustainability<\/td><\/tr>
Metric: launch, adoption, capability<\/td>Metric: reliability, change velocity, unit economics<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Initial build menciptakan asset. Repeat investment menentukan apakah asset tersebut tetap menghasilkan value ketika bisnis berubah. Perusahaan dengan governance yang terlalu fokus mengurangi repeat spending dapat secara tidak sengaja membuat backlog menumpuk, user berpindah ke spreadsheet, integration tertunda, dan software kehilangan relevance. Sebaliknya, repeat investment tanpa prioritization membuat tim terus mengembangkan system tanpa relationship yang jelas terhadap business outcomes.<\/p>\n\n\n\n

Jawabannya bukan menghindari salah satu. Jawabannya adalah mengelola dua investment profile tersebut menggunakan decision rule yang berbeda<\/strong>.<\/p>\n\n\n\n

Jangan Mengukur Kesehatan Software dari \u201cTidak Ada Biaya Lagi\u201d<\/strong><\/h2>\n\n\n\n

Software yang tidak membutuhkan investment selama tiga tahun bisa berarti system sangat stabil. Namun bisa juga berarti bisnis sudah berhenti meminta perubahan karena setiap perubahan terlalu sulit. User kemudian membuat process di Excel, team melakukan manual reconciliation, dan department membeli SaaS sendiri untuk menutup gap.<\/p>\n\n\n\n

Karena itu \u201ctidak ada enhancement cost\u201d bukan metric sustainability yang cukup.<\/p>\n\n\n\n

Metric yang lebih relevan adalah apakah core system masih digunakan, apakah business process tetap berada di dalam controlled workflow, berapa lama perubahan penting membutuhkan implementation, berapa banyak manual workaround, berapa banyak system shadow atau spreadsheet yang muncul, dan apakah integration dengan capability baru masih ekonomis.<\/p>\n\n\n\n

Sistem yang sehat seharusnya dapat berubah secukupnya<\/strong>, bukan tidak pernah berubah.<\/p>\n\n\n\n

TCO Penting, tetapi Jangan Berhenti pada TCO<\/strong><\/h2>\n\n\n\n

Total Cost of Ownership membantu management keluar dari bias initial price. Selain development cost, TCO dapat mempertimbangkan operation, licensing, infrastructure, support, enhancement, integration, migration, dan eventual modernization. Namun TCO tetap hanya sisi cost jika tidak dihubungkan dengan value.<\/p>\n\n\n\n

FinOps Foundation membedakan resource efficiency metrics<\/strong> seperti cost per token, VM, atau GB dengan business unit metrics<\/strong> seperti cost per transaction, customer, atau case resolved. Unit Economics digunakan untuk menghubungkan technology spending dengan value yang dihasilkan organisasi, sehingga peningkatan cost tidak selalu berarti buruk jika business value tumbuh lebih cepat. (FinOps<\/a>) Konsep ini sangat berguna untuk budgeting software enterprise.<\/p>\n\n\n\n

Misalnya Software A memiliki TCO Rp3 miliar selama tiga tahun, sedangkan Software B hanya Rp2 miliar. Jika Software A memproses volume lima kali lebih besar, mengurangi manual operation, mempercepat order cycle, dan mampu menambah business unit baru tanpa project besar, angka Rp3 miliar tidak dapat langsung disebut lebih mahal secara ekonomis.<\/p>\n\n\n\n

Karena itu perusahaan perlu melihat:<\/p>\n\n\n\n

TCO + Outcome + Changeability<\/strong><\/p>\n\n\n\n

bukan hanya:<\/p>\n\n\n\n

TCO.<\/strong><\/p>\n\n\n\n

Crocodic Perspective: Ukur Cost of Change, Bukan Hanya Cost of Ownership<\/strong><\/h2>\n\n\n\n

TCO membantu menjawab berapa banyak uang yang dikeluarkan untuk memiliki dan menjalankan sistem<\/strong>. Namun enterprise yang beroperasi dalam market dinamis membutuhkan metric tambahan: berapa biaya yang diperlukan setiap kali bisnis harus berubah?<\/strong><\/p>\n\n\n\n

Cost of Change dapat mencakup engineering effort, regression testing, data migration, vendor coordination, integration update, downtime risk, user retraining, dan lead time sebelum capability baru tersedia. Dua systems dapat mempunyai annual run cost hampir sama tetapi economics perubahan yang sangat berbeda.<\/p>\n\n\n\n

Crocodic dapat menggunakan framework berikut:<\/p>\n\n\n\n

Software Economic Health = Business Value \u00f7 (Run Cost + Cost of Change + Risk Cost)<\/strong><\/p>\n\n\n\n

Framework ini bukan financial reporting formula. Ia digunakan untuk mendorong management melihat software bukan hanya dari total expense, tetapi dari relationship antara expense, adaptability, dan business outcome.<\/p>\n\n\n\n

Jika Run Cost stabil tetapi Cost of Change terus meningkat, architecture mulai kehilangan adaptability. Jika Modernize investment mampu menurunkan Cost of Change secara material, modernization dapat mempunyai ROI meskipun tidak menghasilkan feature langsung.<\/p>\n\n\n\n

Software enterprise menjadi mahal bukan hanya ketika biaya menjalankannya tinggi, tetapi ketika setiap perubahan bisnis membutuhkan investment yang semakin besar.<\/strong><\/p>\n\n\n\n

Bagaimana Menyusun Budget Software Enterprise untuk 3 Tahun?<\/strong><\/h2>\n\n\n\n

Perusahaan tidak perlu memprediksi seluruh feature tiga tahun ke depan. Forecast semacam itu justru kemungkinan salah. Yang dibutuhkan adalah membuat investment architecture<\/strong> yang mengakui bahwa perubahan akan terjadi meskipun detailnya belum diketahui.<\/p>\n\n\n\n

Tahun 1 \u2014 Build the Capability<\/strong><\/h3>\n\n\n\n

Fokus terbesar berada pada Create: discovery, core implementation, integration foundation, data, deployment, dan adoption. Operate dan Protect juga perlu dimasukkan sejak awal, karena production system harus langsung mempunyai operating baseline.<\/p>\n\n\n\n

Tahun 2 \u2014 Evolve Based on Real Usage<\/strong><\/h3>\n\n\n\n

Setelah penggunaan nyata menghasilkan evidence, Evolve mulai menjadi lebih dominan. Business menemukan workflow yang perlu diubah, system baru perlu diintegrasikan, dan management memperoleh data mengenai bagian mana yang memberikan value tertinggi.<\/p>\n\n\n\n

Tahun 3 \u2014 Optimize and Modernize Selectively<\/strong><\/h3>\n\n\n\n

Architecture mulai memiliki enough operational history untuk mengetahui bottleneck sebenarnya. Beberapa component dapat membutuhkan modernization, sementara capability yang jarang digunakan dapat disederhanakan atau dihentikan. Investment menjadi lebih portfolio-driven.<\/p>\n\n\n\n

Microsoft menyarankan roadmap modernization dimulai dari current portfolio assessment, business goals, prioritization, implementation bertahap, measurement, dan continuous improvement. (Microsoft Learn<\/a>) Mindset yang sama dapat digunakan untuk lifecycle budget: planning tidak harus mengetahui seluruh future requirements, tetapi harus mempunyai mechanism untuk mengalokasikan investment ketika evidence berubah<\/strong>.<\/p>\n\n\n\n

Jangan Membuat Anggaran 3 Tahun dengan Mengalikan Maintenance Tahunan<\/strong><\/h2>\n\n\n\n

Salah satu model sederhana adalah mengambil biaya development kemudian mengasumsikan maintenance sebagai persentase tetap setiap tahun. Model ini mungkin berguna sebagai placeholder awal, tetapi terlalu sederhana untuk software enterprise karena kebutuhan setiap system berbeda.<\/p>\n\n\n\n

Sistem dengan banyak third-party integrations mempunyai Evolve dan Protect requirement berbeda dari application internal sederhana. Platform customer-facing dengan volume tinggi mempunyai Run budget lebih besar. Legacy modernization mempunyai Modernize bucket lebih tinggi. SaaS-heavy architecture mungkin mempunyai license cost lebih tinggi tetapi engineering maintenance lebih rendah.<\/p>\n\n\n\n

Budget karena itu perlu dibangun berdasarkan cost driver<\/strong>, bukan satu percentage universal.<\/p>\n\n\n\n

Beberapa driver yang dapat digunakan:<\/p>\n\n\n\n

Cost Driver<\/strong><\/td>Dampak terhadap Budget<\/strong><\/td><\/tr>
Jumlah business-critical workflows<\/td>Development & testing<\/td><\/tr>
Jumlah integrations<\/td>Evolve & operation<\/td><\/tr>
Transaction volume<\/td>Infrastructure & scalability<\/td><\/tr>
Number of users \/ business units<\/td>Support & access management<\/td><\/tr>
Data sensitivity<\/td>Protect<\/td><\/tr>
Change frequency<\/td>Evolve<\/td><\/tr>
Technical debt<\/td>Modernize<\/td><\/tr>
Vendor \/ platform dependency<\/td>Operate & risk<\/td><\/tr>
Availability requirement<\/td>Run & recovery<\/td><\/tr>
Regulatory change<\/td>Protect & Evolve<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Semakin jelas cost driver, semakin mudah Finance memahami kenapa budget satu system berbeda dengan system lain.<\/p>\n\n\n\n

Planned Maintenance vs Unplanned Remediation<\/strong><\/h2>\n\n\n\n

Tidak semua maintenance harus dipandang sebagai negative cost. Planned maintenance menjaga reliability, security, dependency, backup, dan infrastructure dalam kondisi sehat. Problem terjadi ketika semakin banyak budget digunakan untuk unplanned remediation yang seharusnya tidak berulang.<\/p>\n\n\n\n

Perusahaan dapat memisahkan dua metric:<\/p>\n\n\n\n

Planned Work<\/strong> \u2014 maintenance, upgrade, preventive security, performance review, roadmap enhancement.<\/p>\n\n\n\n

Unplanned Work<\/strong> \u2014 recurring incident, emergency fix, broken integration, manual correction, regression, production firefighting.<\/p>\n\n\n\n

Jika proporsi unplanned work meningkat secara konsisten, menambah maintenance budget tanpa memperbaiki root cause hanya mempertahankan kondisi yang sama. Pada titik tersebut Modernize investment perlu dibandingkan dengan future remediation cost.<\/p>\n\n\n\n

Ini adalah salah satu alasan Enterprise System Upgrade Crocodic<\/a> berfokus memperkuat scalability, integration, multi-user capability, dan AI automation pada existing systems daripada otomatis melakukan replacement. (Crocodic<\/a>) Modernization dapat dilakukan pada bottleneck yang memang meningkatkan cost of operation atau cost of change.<\/p>\n\n\n\n

Budget Cadangan Tidak Sama dengan Budget Tanpa Prioritas<\/strong><\/h2>\n\n\n\n

Karena semua future requirement tidak dapat diketahui, software portfolio membutuhkan capacity reserve. Namun reserve sebaiknya mempunyai decision boundary yang jelas agar tidak berubah menjadi budget bebas.<\/p>\n\n\n\n

Misalnya Evolve reserve dapat digunakan hanya untuk changes yang mempunyai business owner dan measurable outcome. Protect reserve digunakan berdasarkan risk assessment. Modernization reserve memerlukan evidence bahwa current architecture benar-benar menambah cost of change atau risk.<\/p>\n\n\n\n

Dengan cara ini organisasi tetap agile tanpa kehilangan financial governance.<\/p>\n\n\n\n

Salah satu planning structure dapat berupa:<\/p>\n\n\n\n

Committed Budget<\/strong> \u2014 workload yang sudah diketahui.<\/p>\n\n\n\n

Expected Budget<\/strong> \u2014 enhancement atau operation yang kemungkinan besar terjadi.<\/p>\n\n\n\n

Contingency Capacity<\/strong> \u2014 incident, regulatory requirement, atau business change yang belum dapat diprediksi.<\/p>\n\n\n\n

Strategic Reserve<\/strong> \u2014 modernization atau growth initiative yang hanya dilepas setelah business case tersedia.<\/p>\n\n\n\n

Model ini jauh lebih realistis daripada berpura-pura seluruh roadmap tiga tahun dapat diketahui saat project dimulai.<\/p>\n\n\n\n

Kapan Repeat Investment Mulai Menjadi Warning?<\/strong><\/h2>\n\n\n\n

Repeat spending tidak otomatis buruk, tetapi beberapa patterns perlu dianalisis lebih dalam. Misalnya perusahaan mengeluarkan budget untuk memperbaiki integration yang sama berulang kali, enhancement sederhana membutuhkan regression testing sangat besar, hanya satu vendor atau satu engineer yang memahami system, setiap volume increase membutuhkan manual intervention, atau business unit terus membuat workaround di luar application.<\/p>\n\n\n\n

Warning sign lain adalah ketika enhancement budget meningkat tetapi capability delivery justru melambat. Kondisi tersebut menunjukkan company membeli effort<\/strong>, bukan semakin banyak business capability.<\/p>\n\n\n\n

Management dapat memonitor:<\/p>\n\n\n\n