RFP Legacy Modernization: Pilih Custom, SaaS dan ERP?

Ketika legacy system mulai memperlambat perubahan bisnis, perusahaan biasanya memasuki fase yang jauh lebih kompleks daripada sekadar memilih vendor baru. Management perlu menentukan apakah sistem existing masih layak ditingkatkan, apakah lebih tepat diganti dengan SaaS, dipindahkan ke packaged ERP, atau dibangun kembali melalui custom software. Masalahnya, proses procurement sering dimulai terlalu jauh di hilir: perusahaan membuat RFP setelah solusi yang diinginkan sudah diputuskan. Akibatnya, RFP berubah menjadi permintaan harga untuk satu pendekatan tertentu, bukan alat untuk menemukan strategi modernization yang paling masuk akal.

Pendekatan tersebut berisiko karena legacy modernization pada dasarnya bukan keputusan produk. Ia adalah keputusan mengenai business capability mana yang perlu dipertahankan, dependency mana yang perlu dihilangkan, proses mana yang layak distandardisasi, dan bagian mana yang benar-benar membutuhkan customization. Microsoft sendiri menggunakan 6 Rs of application modernization untuk menunjukkan bahwa workload existing tidak selalu harus diganti; pilihan dapat mencakup retain, rehost, replatform, refactor, rebuild, hingga retire berdasarkan architecture, dependency, effort, dan business objective.

Karena itu, RFP yang baik seharusnya tidak dimulai dengan kalimat “Kami membutuhkan ERP baru” atau “Kami ingin membangun ulang sistem secara custom.” RFP sebaiknya dimulai dengan business problem, operating constraint, dan outcome yang harus dicapai, kemudian memberi ruang bagi vendor untuk menunjukkan apakah outcome tersebut lebih tepat dicapai melalui Custom, SaaS, ERP, atau modernization terhadap sistem yang sudah ada.

RFP legacy modernization seharusnya menstandardisasi masalah yang harus diselesaikan, bukan memaksakan solusi sebelum masalah dan economics-nya dipahami.

Legacy Modernization Bukan Sekadar Mengganti Teknologi Lama

Istilah legacy system sering diasosiasikan dengan teknologi yang tua. Padahal usia aplikasi sendiri bukan alasan yang cukup untuk replacement. Sistem lama yang masih reliable, aman, mudah diintegrasikan, dan ekonomis untuk diubah dapat tetap menjadi business asset yang berharga. Sebaliknya, sistem yang relatif baru dapat menjadi legacy problem jika architecture-nya membuat setiap perubahan bisnis membutuhkan effort yang tidak proporsional.

Legacy modernization menjadi relevan ketika struktur sistem mulai menciptakan business friction: release semakin lambat, integration sulit dikembangkan, manual workaround terus bertambah, security update semakin kompleks, dependency terhadap individu atau vendor terlalu tinggi, atau business unit mulai menggunakan spreadsheet dan shadow tools karena sistem utama tidak cukup adaptable. AWS melalui Application Portfolio Assessment Guidance menempatkan discovery, analysis, dan planning sebagai bagian penting sebelum menentukan migration atau modernization strategy. Artinya, keputusan sebaiknya dimulai dengan memahami portfolio dan dependency, bukan langsung memilih teknologi pengganti.

Crocodic membahas keputusan tersebut dari sisi architecture dalam Refactor vs Rewrite: Kapan Sistem Lama Harus Dibangun Ulang?. Artikel tersebut berfokus pada keputusan apakah existing system masih dapat diperbaiki atau perlu dibangun kembali. RFP modernization mengambil langkah berikutnya: bagaimana perusahaan menerjemahkan keputusan tersebut menjadi procurement document yang memungkinkan beberapa opsi solusi dibandingkan secara objektif.

Jangan Membandingkan Custom, SaaS, dan ERP Sebelum Mendefinisikan Apa yang Dibandingkan

Salah satu problem terbesar dalam RFP adalah perusahaan meminta proposal dari tiga vendor yang sebenarnya menawarkan tiga hal berbeda, kemudian membandingkan angka akhirnya seolah-olah semuanya merupakan substitusi yang setara. Vendor pertama mungkin menawarkan custom software yang seluruh workflow-nya mengikuti perusahaan. Vendor kedua menawarkan SaaS dengan konfigurasi terbatas tetapi deployment cepat. Vendor ketiga menawarkan packaged ERP yang membawa standard process, implementation partner, module license, dan integration requirement.

Perlu diperjelas bahwa istilah SaaS dan ERP tidak selalu merupakan kategori yang sepenuhnya terpisah. ERP modern dapat dikonsumsi sebagai SaaS, sementara SaaS dapat mencakup berbagai jenis aplikasi bisnis. Dalam konteks RFP ini, “SaaS” digunakan untuk menggambarkan specialized packaged application yang sebagian besar prosesnya mengikuti capability produk, sedangkan “ERP” mengacu pada packaged enterprise platform yang menghubungkan beberapa fungsi operasional melalui module dan process model yang lebih luas.

Karena economic model, responsibility, customization limit, dan implementation approach ketiganya berbeda, perusahaan membutuhkan baseline yang sama sebelum melakukan commercial comparison.

RFP yang sehat tidak harus meminta seluruh vendor menawarkan keempat opsi. Namun decision committee perlu menggunakan dimensi yang sama ketika membandingkan business case dari masing-masing pendekatan.

Prinsip Pertama: Mulai RFP dari Business Outcome, Bukan Product Requirement

RFP modernization sebaiknya menjelaskan problem dengan bahasa bisnis. Misalnya, daripada menulis “membutuhkan ERP dengan modul procurement, inventory, dan finance”, perusahaan dapat menjelaskan bahwa purchase-to-pay process saat ini tersebar di beberapa aplikasi, terdapat duplicate data entry, approval sulit dilacak, inventory tidak real-time, dan reconciliation membutuhkan pekerjaan manual.

Perbedaan ini terlihat kecil, tetapi secara strategis sangat penting. Requirement pertama sudah mengunci solution architecture sebelum vendor melakukan assessment. Requirement kedua memberikan ruang untuk menentukan apakah seluruh masalah memang membutuhkan ERP replacement atau sebagian dapat diselesaikan melalui integration, workflow modernization, dan upgrade terhadap existing system.

Untuk capability yang sangat spesifik terhadap cara perusahaan beroperasi, Custom Enterprise Software dapat menjadi salah satu pendekatan. Untuk sistem existing yang core business logic-nya masih bernilai tetapi membutuhkan scalability, multi-user capability, API integration, atau automation, Enterprise System Upgrade dapat menjadi opsi tanpa otomatis melakukan rebuild dari nol. Kedua layanan tersebut mewakili dua economic choices yang berbeda: membangun capability baru atau mempertahankan investment yang masih memiliki value.

Framework RFP: Delapan Area yang Harus Dibandingkan

Agar Custom, SaaS, ERP, dan modernization dapat dievaluasi secara lebih objektif, RFP sebaiknya tidak hanya berisi functional requirement. Procurement committee perlu mengevaluasi setidaknya delapan area: business fit, process change, legacy dependency, integration, data migration, security and ownership, lifecycle economics, serta implementation risk.

Framework tersebut sengaja tidak memasukkan jumlah fitur sebagai dimensi utama. Dalam modernization, fitur yang sama dapat memiliki konsekuensi economics berbeda tergantung architecture, dependency, dan operating model.

1. Business Fit: Mana Capability yang Harus Mengikuti Perusahaan?

Pertanyaan pertama bukan apakah Custom lebih fleksibel daripada SaaS atau ERP. Itu sudah cukup jelas secara konseptual. Pertanyaan yang lebih relevan adalah berapa banyak flexibility yang benar-benar bernilai bagi perusahaan.

Tidak semua process perlu customized. Payroll standard, collaboration, expense management sederhana, atau berbagai supporting process sering dapat mengikuti standard market solution. Mempertahankan keunikan pada proses commodity justru dapat membuat organisasi membayar complexity tanpa differentiation.

Sebaliknya, ada process yang menentukan bagaimana perusahaan menghasilkan revenue, mengelola supply chain, menjalankan approval khusus, menghubungkan partner ecosystem, atau memberikan customer experience. Jika process tersebut merupakan competitive capability, memaksa organisasi mengikuti limitation software generik dapat mengurangi strategic value.

Karena itu, RFP sebaiknya meminta vendor mengklasifikasikan requirement menjadi standard capability, configurable capability, custom capability, dan process change required. Hasilnya akan jauh lebih informatif dibanding sekadar checklist “available/not available”.

Crocodic membahas logic keputusan ini dalam Build, Buy, atau Extend? Mana Strategi yang Paling Aman, dengan prinsip bahwa capability commodity cenderung cocok dibeli, differentiation dapat membutuhkan custom control, sementara existing asset yang masih bernilai dapat diperluas atau dimodernisasi.

2. Process Change: Hitung Harga dari Standardisasi

SaaS dan ERP sering menawarkan implementation yang lebih cepat karena perusahaan tidak perlu mendesain seluruh system behavior dari nol. Namun kecepatan tersebut biasanya datang bersama operating model tertentu. Organisasi harus menentukan seberapa jauh process existing bersedia diubah agar sesuai dengan software.

Hal ini bukan kelemahan. Standardization dapat menjadi alasan kuat memilih packaged solution. Jika legacy process sebenarnya terlalu kompleks karena historical workaround, modernization justru merupakan kesempatan untuk menyederhanakan operasi. Masalah muncul ketika process yang memberikan differentiation dipaksa mengikuti product limitation hanya karena implementation terlihat lebih sederhana.

Karena itu, RFP sebaiknya meminta setiap vendor menjelaskan process fit-gap. Untuk setiap critical workflow, vendor harus menunjukkan apakah requirement dapat dipenuhi secara native, melalui configuration, extension, customization, integration, atau membutuhkan perubahan process di sisi client.

Dengan struktur seperti ini, management dapat melihat bahwa “fit 80%” belum tentu baik atau buruk. Yang penting adalah 20% yang tidak fit berada di bagian mana. Gap pada laporan internal minor tentu berbeda dampaknya dengan gap pada core pricing engine atau production workflow.

3. Legacy Dependency: Tentukan Apa yang Harus Dipertahankan

Legacy modernization yang baik tidak dimulai dengan asumsi bahwa seluruh existing system buruk. Perusahaan perlu mengidentifikasi bagian mana yang masih memiliki business value: business logic, historical data, integration, operational knowledge, user adoption, atau capability tertentu yang sudah stabil.

Microsoft melalui 6 Rs framework mendorong evaluasi modernization berdasarkan architecture, dependency, dan level of effort, bukan menggunakan satu strategi untuk seluruh workload. Sebagian aplikasi dapat dipertahankan, sebagian dipindahkan, sebagian di-refactor, sementara bagian lain memang layak dibangun kembali atau dihentikan.

Karena itu, RFP perlu meminta vendor menjelaskan target-state architecture dan transition strategy. Jangan hanya meminta diagram solusi baru. Minta vendor menunjukkan apa yang terjadi pada existing system selama transisi, integration mana yang tetap aktif, data mana yang dipindahkan, interface mana yang harus coexist, dan kapan component lama dapat dinonaktifkan.

Ini sangat penting untuk menghindari modernization yang secara teori mengganti legacy system tetapi secara praktik justru menambahkan satu layer teknologi baru di atas dependency lama.

4. Integration: Jangan Membiarkan RFP Berhenti pada “Bisa Terintegrasi”

Hampir semua vendor enterprise software akan mengatakan bahwa platform mereka dapat diintegrasikan. Pernyataan tersebut terlalu umum untuk procurement decision. RFP perlu menjelaskan system landscape dan meminta response yang konkret mengenai source of truth, API availability, authentication, data ownership, synchronization, error handling, retry mechanism, observability, serta responsibility jika integration melibatkan vendor ketiga.

Pada Custom Software, integration dapat dibangun mengikuti kebutuhan architecture perusahaan, tetapi engineering ownership lebih besar. Pada SaaS, perusahaan perlu memahami API limitation, rate limit, event availability, licensing tier, dan bagaimana vendor mengelola versioning. Pada packaged ERP, integration dapat menggunakan standard connector atau integration platform, tetapi customization dan data mapping dapat menciptakan complexity tersendiri.

Karena itu, jangan membandingkan hanya “integration included” versus “integration included.” Bandingkan integration boundary dan responsibility model.

5. Data Migration: Pisahkan Data Movement dari Data Readiness

Data migration merupakan salah satu area yang dapat mengubah timeline dan risk profile modernization secara drastis. Legacy system sering menyimpan duplicate record, inconsistent identifier, historical business rules, obsolete field, atau data semantics yang berbeda dari target platform. Memindahkan record bukan bagian tersulit; memastikan data tetap memiliki arti yang benar setelah dipindahkan jauh lebih penting.

RFP sebaiknya meminta vendor menjelaskan data profiling, mapping, cleansing responsibility, migration rehearsal, validation, reconciliation, archival, cutover, dan rollback strategy. Jika SaaS atau ERP memiliki standard data model, perusahaan juga perlu memahami bagaimana legacy data dipetakan ke struktur tersebut. Jika menggunakan custom software, fleksibilitas data model lebih tinggi, tetapi perusahaan tetap perlu menghindari sekadar mereplikasi struktur lama ke platform baru tanpa memperbaiki underlying problem.

AWS menempatkan discovery dan analysis sebagai komponen utama dalam portfolio assessment karena dependency dan kondisi workload harus diketahui sebelum migration atau modernization plan dapat dibuat secara kredibel.

6. Security, Ownership, dan Vendor Dependency Harus Masuk ke RFP

Security requirement tidak sebaiknya dimasukkan sebagai checkbox “vendor harus mengikuti best practice”. Procurement perlu meminta evidence yang lebih konkret sesuai tingkat risiko sistem.

NIST memiliki Software Supply Chain Security Guidance yang secara khusus ditujukan antara lain kepada procurement dan technology professionals untuk membantu menentukan informasi apa yang perlu diminta dari software producers mengenai secure software development practices. Panduan tersebut menunjukkan bahwa acquisition process memang memiliki peran langsung dalam software security, bukan hanya tim engineering setelah vendor dipilih.

Dalam RFP enterprise, perusahaan dapat meminta penjelasan mengenai secure development process, vulnerability management, identity and access control, audit log, encryption, incident handling, third-party component, data residency bila relevan, serta software supply chain. NIST juga memberikan panduan mengenai penggunaan informasi seperti Software Bill of Materials atau SBOM untuk membantu memahami third-party software component dalam supply chain.

Ownership juga perlu dijelaskan secara eksplisit. Untuk custom software, siapa memiliki source code, repository, documentation, dan deployment asset? Untuk SaaS, bagaimana data export dilakukan jika contract berhenti? Untuk ERP, mana configuration yang dapat dibawa dan mana yang proprietary? Vendor dependency tidak harus dihilangkan, tetapi exit path harus diketahui sebelum entry decision dibuat.

7. Bandingkan Lifecycle Economics, Bukan Hanya Implementation Fee

Custom, SaaS, dan ERP memiliki cost structure berbeda sehingga membandingkan initial proposal saja dapat menghasilkan keputusan yang salah. Custom software umumnya memiliki initial engineering commitment lebih besar tetapi dapat memberikan control lebih tinggi terhadap workflow dan architecture. SaaS cenderung memindahkan sebagian besar technology ownership kepada vendor melalui subscription, tetapi recurring cost dapat berubah seiring user, usage, module, atau pricing model. ERP packaged dapat memiliki kombinasi license, implementation, integration, customization, support, dan upgrade cost yang perlu dilihat dalam horizon beberapa tahun.

RFP sebaiknya meminta vendor menjelaskan setidaknya lima lapisan economics: Acquire, Implement, Run, Change, dan Exit. Acquire mencakup license atau development commitment. Implement mencakup configuration, customization, migration, training, dan integration. Run mencakup infrastructure, subscription, support, maintenance, dan monitoring. Change menggambarkan biaya ketika process atau integration berubah. Exit menggambarkan konsekuensi ketika perusahaan ingin mengganti vendor atau technology strategy.

Prinsipnya:

Solusi dengan implementation cost terendah belum tentu memiliki lifecycle economics terbaik, dan solusi dengan fleksibilitas tertinggi belum tentu menghasilkan business value terbaik.

RFP harus membuat trade-off tersebut terlihat sebelum kontrak ditandatangani.

8. Implementation Risk: Evaluasi Cara Berpindah, Bukan Hanya Target System

Legacy modernization biasanya terjadi pada sistem yang sudah digunakan. Karena itu, risiko terbesar bukan hanya apakah target system dapat bekerja, tetapi bagaimana perusahaan berpindah dari kondisi sekarang menuju kondisi baru tanpa mengganggu operasi.

RFP perlu meminta migration roadmap yang menjelaskan phased rollout, pilot, coexistence, data cutover, user adoption, fallback, rollback, training, serta decommission strategy. Big-bang replacement dapat masuk akal pada kondisi tertentu, tetapi pada core enterprise system risikonya perlu dibandingkan dengan pendekatan incremental.

AWS mendeskripsikan modernization sebagai upaya incremental yang menggunakan data untuk memahami legacy environment dan memilih pendekatan yang sesuai, dan juga menyediakan phased approach to application modernizationuntuk membangun roadmap secara bertahap.

Ini berarti proposal vendor tidak seharusnya hanya dinilai dari future-state architecture yang menarik. Procurement perlu menilai transition architecture—bagaimana bisnis tetap berjalan selama sistem berada di antara legacy dan target state.

RFP Evaluation Matrix: Custom vs SaaS vs ERP

Setelah requirement dan response vendor dinormalisasi, perusahaan dapat menggunakan evaluation matrix berikut sebagai dasar diskusi lintas management, IT, procurement, finance, dan business owner.

Bobot sebaiknya tidak dibuat universal. Manufacturing company dengan core production workflow mungkin memberi business fit dan integration bobot lebih tinggi. Organisasi yang ingin mengganti banyak fragmented tools dengan standard enterprise process dapat lebih memprioritaskan standardization dan adoption. Perusahaan dengan regulatory exposure tinggi akan menempatkan security, auditability, dan data control lebih tinggi.

Yang penting, semua vendor dinilai melalui business criteria yang sama.

Jangan Meminta Vendor Memilih Solusi untuk Problem yang Belum Terdefinisi

Vendor memang dapat membantu discovery, tetapi perusahaan tetap perlu memiliki internal clarity terhadap problem yang sedang diselesaikan. Jika RFP terlalu abstrak, setiap vendor akan menginterpretasikan requirement sesuai solusi yang mereka jual. SaaS vendor akan menunjukkan mengapa konfigurasi produk cukup. ERP partner akan menjelaskan manfaat standard enterprise platform. Custom software vendor akan menekankan flexibility.

Semua argumen tersebut dapat benar.

Tetapi semuanya berasal dari solution perspective masing-masing.

Karena itu, sebelum RFP dikirim, perusahaan idealnya menyelesaikan modernization assessment yang menjawab business outcome, current pain point, process priority, data landscape, system dependency, risk, dan target operating model. Setelah itu, vendor diberi ruang untuk mengusulkan solution architecture.

Pendekatan ini juga membuat Vendor Selection menjadi lebih efektif. Vendor selection seharusnya menilai apakah partner memahami problem, mampu melakukan assessment, memiliki metodologi, dapat menjelaskan trade-off, dan memiliki capability untuk mendukung sistem setelah initial delivery—bukan sekadar apakah vendor memiliki daftar client panjang atau memberikan proposal paling murah.

Perspektif Crocodic: Preserve Optionality Before Selecting Technology

Legacy modernization mudah berubah menjadi technology debate. Custom dianggap paling fleksibel. SaaS dianggap paling cepat. ERP dianggap paling terintegrasi. Masing-masing klaim memiliki konteks di mana ia benar, tetapi tidak satu pun dapat digunakan sebagai keputusan default.

Perspektif Crocodic adalah:

RFP modernization harus mempertahankan solution optionality selama mungkin, lalu mempersempit pilihan berdasarkan business fit, lifecycle economics, dan cost of change.

Perusahaan sebaiknya tidak membangun custom software untuk process yang sebenarnya dapat distandardisasi dengan baik. Perusahaan juga tidak seharusnya membeli SaaS atau ERP hanya karena implementation terlihat cepat jika critical workflow akhirnya membutuhkan workaround besar. Existing system juga tidak perlu dibuang jika core capability masih bernilai dan limitation utamanya dapat diselesaikan melalui architecture improvement atau integration.

Inilah perbedaan antara technology replacement dan business modernization. Technology replacement bertanya software apa yang akan menggantikan legacy system. Business modernization bertanya architecture dan operating model apa yang memungkinkan organisasi bekerja lebih baik setelah perubahan selesai.

Checklist Sebelum RFP Dikirim ke Vendor

Sebelum procurement memulai tender atau vendor evaluation, management perlu memastikan RFP sudah menjawab beberapa pertanyaan mendasar. Business outcome harus jelas dan tidak hanya berupa daftar fitur. Critical workflow perlu dibedakan dari process yang dapat distandardisasi. Existing application dan dependency perlu dipetakan. Data condition harus diketahui pada level yang cukup untuk memperkirakan migration risk. Integration landscape, identity, security requirement, audit, dan compliance perlu masuk sejak awal. Vendor juga harus diminta menjelaskan assumption, exclusion, target architecture, transition architecture, commercial model, recurring cost, change mechanism, ownership, serta exit strategy.

RFP sebaiknya juga meminta vendor menunjukkan apa yang tidak perlu dibangun. Kemampuan vendor mengurangi scope melalui reuse, standard capability, modernization bertahap, atau process simplification dapat sama bernilainya dengan kemampuan menambahkan fitur.

RFP yang baik bukan dokumen yang paling panjang. RFP yang baik adalah dokumen yang membuat proposal vendor dapat dibandingkan berdasarkan problem, outcome, responsibility, risk, dan economics yang sama.

Kesimpulan

Memilih antara Custom Software, SaaS, ERP, atau modernisasi terhadap existing system seharusnya bukan keputusan pertama dalam legacy modernization. Keputusan pertama adalah memahami business capability apa yang perlu diperbaiki, limitation apa yang benar-benar berasal dari legacy architecture, dan perubahan apa yang ingin dicapai oleh perusahaan.

Setelah itu, RFP dapat digunakan untuk membuat pilihan teknologi menjadi lebih objektif. Business fit menunjukkan seberapa jauh solusi mendukung critical workflow. Process fit memperlihatkan bagian bisnis yang harus distandardisasi. Legacy assessment menentukan asset yang tetap perlu dipertahankan. Integration dan data migration menunjukkan transition complexity. Security dan ownership mengungkap operational dependency. Lifecycle economics menunjukkan apakah solution tetap masuk akal setelah implementation. Implementation plan menunjukkan seberapa aman organisasi dapat berpindah dari kondisi existing menuju target state.

Karena itu, RFP modernization sebaiknya tidak bertanya:

“Mana yang lebih baik: Custom, SaaS, atau ERP?”

Pertanyaan yang lebih berguna adalah:

“Untuk business outcome, dependency, risk, dan economics perusahaan kami, pendekatan mana yang memberikan target state paling adaptif dengan transition risk yang dapat diterima?”

Jawaban terhadap pertanyaan tersebut dapat berbeda pada setiap perusahaan—dan bahkan berbeda pada setiap application di dalam perusahaan yang sama.

Modernisasi Sistem Enterprise Bersama Crocodic

Crocodic membantu perusahaan mengevaluasi dan meningkatkan sistem existing melalui Enterprise System Upgrade, termasuk peningkatan scalability, multi-user access, API integration, dan automation tanpa selalu membangun ulang sistem dari awal.

Untuk business capability yang membutuhkan workflow, data model, integration, atau operating logic yang spesifik, Custom Enterprise Software membantu perusahaan membangun sistem berdasarkan cara kerja bisnis, bukan memaksa proses mengikuti limitation software generik.

Sebelum menentukan solusi, Crocodic melihat modernization sebagai keputusan mengenai apa yang perlu dipertahankan, apa yang perlu diperbaiki, dan apa yang memang perlu dibangun ulang. Pendekatan ini membantu perusahaan menghindari replacement yang tidak perlu sekaligus memastikan sistem existing tidak terus dipertahankan ketika cost of change sudah menjadi hambatan bisnis.

Diskusikan strategi legacy modernization dan kebutuhan sistem enterprise Anda bersama Crocodic.