Apa itu Function Point Analysis? Metode Objektif Menghitung Kompleksitas Proyek ERP

Function Point Analysis ERP – Pernahkah Anda berada di situasi ini: Anda sudah menyetujui anggaran 1 Miliar Rupiah untuk implementasi ERP baru. Namun, enam bulan berjalan, vendor datang kembali dan berkata, “Pak/Bu, ada tambahan biaya 800 juta untuk kustomisasi.”

Pusing tujuh keliling, bukan?

Atau skenario lain: Anda membandingkan proposal dari dua vendor IT. Keduanya menjanjikan hasil yang sama. Tapi Vendor A mengajukan 500 jam kerja, sementara Vendor B mengajukan 2.000 jam kerja.

Siapa yang benar? Dan yang lebih penting, bagaimana Anda tahu bahwa biaya software yang akan Anda bayar itu wajar dan objektif?

Ini adalah masalah klasik dalam estimasi proyek IT. Subjektivitas adalah musuh utamanya. Estimasi berbasis “jam kerja” atau “perasaan konsultan” seringkali lebih mirip seni meramal daripada ilmu pasti. Akibatnya, proyek ERP—yang terkenal kompleks dan penuh kustomisasi—sering kali molor dari jadwal dan membengkak anggarannya.

Nah, di sinilah Function Point Analysis (FPA) untuk ERP hadir sebagai solusi.

Bayangkan FPA sebagai “penggaris” standar yang objektif untuk mengukur ukuran sebuah perangkat lunak. Alih-alih menghitung jam kerja (upaya) atau baris kode (teknis), FPA menghitung fungsionalitas yang diterima oleh pengguna.

Secara sederhana, Function Point Analysis (FPA) mengukur ukuran fungsional perangkat lunak dengan menilai fitur dan fungsi dari sudut pandang pengguna. Selain itu, metode ini menghasilkan angka yang disebut Function Points (FP) yang tidak tergantung pada teknologi, bahasa pemrograman, atau platform. Oleh karena itu, FPA menjadi alat yang tepat untuk menghitung kompleksitas proyek secara objektif, terutama di lingkungan ERP dengan beragam teknologi.

Mari kita bedah lebih dalam mengapa metode ini bisa menjadi “formula harga software” yang transparan untuk proyek IT Anda.

Masalah Klasik Proyek ERP: Kenapa Estimasi Sering Melenceng?

Mari kita jujur. Proyek implementasi ERP itu rumit, mahal, dan sering kali… menakutkan. Tantangan terbesarnya bukanlah pada software standar yang Anda beli, melainkan pada kustomisasi ERP.

Setiap bisnis di Indonesia punya proses unik. Ada yang butuh alur persetujuan budget yang berlapis-lapis, ada yang perlu laporan pajak khusus yang tidak ada di standar, atau butuh integrasi ke sistem legacy yang sudah berumur puluhan tahun. Kebutuhan kustomisasi inilah yang membuat estimasi proyek jadi kacau balau.

Metode estimasi tradisional seperti menghitung Baris Kode (Lines of Code/LOC) sama sekali tidak berguna di sini. Seratus baris kode di SAP (menggunakan bahasa ABAP) tentu tidak sama fungsionalitasnya dengan seratus baris kode di Java untuk interface web. Ini seperti membandingkan berat apel dengan berat durian; keduanya buah, tapi bobot dan kompleksitasnya (apalagi aromanya!) jelas berbeda.

Tanpa “penggaris” yang objektif, estimasi biaya kustomisasi ERP akhirnya hanya berdasarkan “perasaan” atau “pengalaman” konsultan. Tentu saja, ini membuka risiko besar terjadinya pembengkakan biaya (cost overrun) dan ketidakpuasan di kemudian hari.

Apa Itu Function Point Analysis (FPA)? Mengukur Nilai, Bukan Sekadar Kode

Function Point Analysis (FPA) sebenarnya bukan barang baru. Metode FPA ini pertama kali diperkenalkan pada tahun 1979 oleh Allan J. Albrecht dari IBM. Tujuannya saat itu sangat jelas: menciptakan cara untuk mengukur produktivitas pengembangan software tanpa terjebak dalam perdebatan teknologi atau bahasa pemrograman.

Sejak itu, metode ini telah disempurnakan dan distandarisasi oleh International Function Point User’s Group (IFPUG), yang kini diakui sebagai standar ISO global.

Filosofi unik FPA inilah yang menciptakan keajaibannya sendiri. Daripada sekadar menghitung jumlah kode dari sudut pandang developer, FPA justru lebih menekankan pada fungsionalitas bisnis yang benar-benar pengguna dapatkan. Akibatnya, fokus pun secara alami beralih ke perspektif bisnis yang lebih relevan.

Inilah yang membuatnya disebut sebagai “metode objektif”.

FPA memungkinkan seorang CIO atau Manajer IT untuk membandingkan produktivitas tim implementasi SAP internal dengan tim outsourcing yang membangun aplikasi web, menggunakan metrik yang sama: Biaya per Function Point atau Jam Kerja per Function Point. Fokusnya bergeser dari “seberapa sulit membuatnya?” menjadi “seberapa banyak fungsionalitas yang saya dapatkan?”.

Membedah FPA: 5 Komponen Inti Fungsionalitas

Jadi, bagaimana FPA “mengukur” luas sebuah software? Metode IFPUG pada dasarnya memecah semua fungsionalitas sistem menjadi lima komponen standar. Agar mudah dipahami, kita bisa membaginya menjadi dua kategori sederhana:

1. Fungsi Data (Tempat Penyimpanan Data)

Ini adalah data yang disimpan oleh sistem. Bayangkan ini adalah “gudang” atau “ruangan” dalam aplikasi Anda.

• Internal Logical Files (ILF): Ini adalah data yang dikelola dan disimpan di dalam batas aplikasi Anda. Dalam ERP, ini adalah master data inti.
  • Contoh ERP: Tabel Master Data Karyawan, Tabel Master Data Material, Daftar Pesanan Penjualan.
• External Interface Files (EIF): Ini adalah data yang digunakan oleh aplikasi Anda, tetapi sebenarnya dikelola atau disimpan di luar sistem (misalnya oleh aplikasi lain).
  • Contoh ERP: Data kurs mata uang yang diambil dari API Bank Indonesia, data NPWP yang divalidasi ke sistem Pajak, atau data dari sistem payroll pihak ketiga.

2. Fungsi Transaksional (Aktivitas Pengguna)

Ini adalah proses yang memindahkan data. Jika data adalah “ruangan”, ini adalah “pintu, jendela, dan koridor” yang memungkinkan pengguna berinteraksi dengan data tersebut.

• External Inputs (EI): Proses di mana pengguna memasukkan data baru ke dalam sistem yang mengubah data internal (ILF).
  • Contoh ERP: Formulir “Tambah Karyawan Baru”, layar “Input Purchase Order” (misalnya T-Code ME21N di SAP), atau proses upload data invoice bulanan.
• External Outputs (EO): Proses di mana sistem menyajikan data kepada pengguna, tetapi data tersebut sudah melalui pemrosesan, kalkulasi, atau logika bisnis terlebih dahulu.
  • Contoh ERP: Menampilkan Laporan Laba Rugi bulanan (yang menjumlahkan banyak data), proses cetak invoice (yang menggabungkan data pelanggan dan produk), atau laporan analisis performa vendor.
• External Inquiries (EQ): Proses di mana pengguna mengambil atau mencari data dari sistem tanpa ada kalkulasi kompleks. Pada dasarnya, ini adalah fungsi “cari” atau “tampilkan data”.
  • Contoh ERP: Layar “Cari Karyawan berdasarkan ID”, fungsi “Lihat Saldo Stok Material” (misal: MMBE di SAP), atau “Tampilkan detail invoice“.

Setelah mengidentifikasi kelima komponen itu, seorang analis FPA langsung bisa memetakan seluruh ruang lingkup proyek ERP. Bahkan, pendekatan ini tetap efektif sekalipun kustomisasi yang diminta terbilang kecil.

Bagaimana FPA Menjadi “Formula Harga Software” yang Objektif? (3 Langkah)

Setelah kita tahu ada 5 komponen, bagaimana kita bisa sampai pada satu angka FP yang menjadi formula harga software? Prosesnya terdiri dari tiga langkah utama. Ini mungkin terlihat sedikit teknis, tapi sangat penting untuk memahami objektivitasnya.

Langkah 1: Menghitung Ukuran ‘Mentah’ (Unadjusted Function Point – UFP)

Pertama, kita tidak hanya menghitung jumlah komponen. Setiap komponen (misalnya, 1 layar EI) tidak dihitung sebagai “satu”. Ia diberi skor kompleksitas: Rendah, Rata-rata (Average), atau Tinggi.

Bagian terbaiknya? Penilaian kompleksitas ini tidak subjektif atau berdasarkan “perasaan”. Penentuannya didasarkan pada penghitungan elemen-elemen yang lebih kecil lagi secara spesifik:

• Data Element Type (DET): Jumlah field unik yang diisi pengguna (misal: Nama, Alamat, NIK).
• Record Element Type (RET): Jumlah tabel logis yang disentuh (misal: tabel Karyawan, tabel Departemen).
• File Type Referenced (FTR): Jumlah file (ILF/EIF) yang diakses oleh transaksi tersebut.

Berdasarkan jumlah DET, RET, dan FTR, analis akan merujuk ke matriks standar IFPUG untuk menentukan apakah sebuah komponen itu Rendah, Rata-rata, atau Tinggi.

Setelah itu, setiap komponen dikalikan dengan bobot standar IFPUG (misalnya, EI-Rendah = 3 poin, ILF-Tinggi = 15 poin). Total dari semua ini disebut Unadjusted Function Point (UFP).

Langkah 2: Menyesuaikan Kompleksitas Teknis (Value Adjustment Factor – VAF)

Langkah ini menjawab pertanyaan, “Seberapa rumit lingkungan teknis proyek ini?”

Analis FPA akan menilai 14 General System Characteristics (GSC) atau Karakteristik Sistem Umum. Ini adalah faktor-faktor non-fungsional yang memengaruhi upaya pengerjaan. Bayangkan ini sebagai “faktor kesulitan” atau “medan tempur” dari proyek tersebut.

Contoh dari 14 GSC tersebut antara lain:

• Apakah sistem membutuhkan komunikasi data yang berat? (Misal: integrasi real-time).
• Apakah ada tuntutan performance (kecepatan respons) yang sangat tinggi?
• Apakah logika pemrosesannya sangat kompleks (misal: perhitungan algoritma forecasting).
• Apakah sistem dirancang untuk mudah diinstal di banyak lokasi berbeda?
• Apakah kode harus sangat bisa digunakan kembali (reusable)?

Anda berikan skor pada setiap karakteristik ini, mulai dari 0 (tidak ada pengaruh) hingga 5 (sangat penting). Selanjutnya, masukkan total skor dari 14 GSC ini—yang kita sebut TDI—ke rumus standar guna menghasilkan Value Adjustment Factor (VAF).

Nilai VAF ini berkisar antara 0,65 (jika proyek sangat sederhana) hingga 1,35 (jika proyek sangat rumit). Ini berarti kompleksitas teknis dapat menyesuaikan ukuran akhir proyek sebesar plus atau minus 35%.

Langkah 3: Perhitungan Akhir (Adjusted Function Point)

Ini adalah langkah paling sederhana. Kita tinggal mengalikan ukuran mentah dengan faktor kesulitan teknisnya:

Function Point (FP) Akhir = Unadjusted Function Point (UFP) x Value Adjustment Factor (VAF)

Angka FP akhir inilah yang menjadi ukuran objektif dari perangkat lunak Anda. Sebuah proyek sederhana mungkin berukuran 150 FP, sementara implementasi ERP skala besar bisa mencapai 5.000 FP atau lebih.

Aplikasi Nyata FPA untuk Proyek ERP Anda

Mengetahui ukuran FP tentu sangat bagus, tapi bagaimana ini membantu Anda dalam estimasi proyek IT sehari-hari di lapangan?

Menghitung Kustomisasi dan Modul Tambahan

Inilah kekuatan terbesar FPA dalam proyek ERP. Bayangkan Anda meminta satu kustomisasi kecil: saya ingin menambahkan 5 field baru pada layar Sales Order. Selain itu, 2 field di antaranya perlu melakukan validasi silang secara real-time dengan data stok dari sistem gudang eksternal.

Bagi konsultan, ini bisa berarti estimasi “kira-kira 80 jam kerja”. Tapi dari mana angka itu berasal? Rasanya seperti angka yang muncul dari langit.

Dengan FPA, prosesnya menjadi transparan:

1. Function Point Analysis ERP mengidentifikasi ini sebagai Enhancement Project (proyek modifikasi).
2. Mereka mulai menghitung 1 EI, yaitu layar Sales Order yang sudah mereka modifikasi. Selain itu, mereka juga mencatat 1 ILF, seperti tabel Sales Order yang kemungkinan ikut berubah. Akhirnya, mereka tambahkan 1 EIF, yakni sistem gudang eksternal yang baru saja mereka akses.
3. Mereka menghitung kompleksitas baru berdasarkan jumlah DET, RET, dan FTR yang terlibat.
4. Hasilnya: “Perubahan ini berukuran 12 FP.”

Negosiasi Anda dengan vendor kini berubah total. Anda tidak lagi berdebat soal “jam kerja” yang subjektif. Anda menyetujui biaya berdasarkan ukuran objektif: Biaya per Function Point.

Konversi FPA ke Jam Kerja (Man-Hours) dan Biaya

Satu hal yang harus sangat jelas: Function Point Analysis ERP adalah ukuran ukuran (size), BUKAN ukuran upaya (effort/jam kerja).

Untuk mengubah ukuran menjadi upaya, Anda memerlukan satu metrik kunci lagi: Tingkat Produktivitas (Productivity Rate) tim Anda.

Total Upaya (Jam Kerja) = Total Function Points x (Rata-rata Jam per FP)

Organisasi Anda atau vendor Anda idealnya mengumpulkan metrik “Jam per FP” (atau konversi function point ke man hour) sebagai data historis dari proyek-proyek sebelumnya.

Nilai ini sangat bervariasi. Mungkin tim developer Java Anda memiliki produktivitas 10 Jam/FP, sementara tim ERP Anda 12 Jam/FP karena platformnya lebih kompleks.

Setelah Anda memiliki angka ini, estimasi proyek IT menjadi sangat transparan:

Estimasi Biaya = Total FP x (Rata-rata Jam/FP) x (Biaya per Jam)

Contoh: 12 FP (ukuran kustomisasi) x 12 Jam/FP (produktivitas tim ERP Anda) x Rp 500.000/Jam (biaya rata-rata konsultan) = Rp 72.000.000

Kini, jika vendor meminta biaya Rp 100.000.000, Anda bisa bertanya secara objektif: “Apakah produktivitas tim Anda lebih rendah dari 12 Jam/FP, atau biaya per jam Anda lebih tinggi?” Diskusinya menjadi berbasis data, bukan asumsi.

Perbandingan FPA: Apakah Masih Relevan di Era Agile vs Story Points?

Ini adalah perdebatan paling seru di manajemen proyek modern. Banyak tim Agile/Scrum yang fanatik akan bilang, “Kami sudah pakai Story Points, FPA itu kuno dan tidak relevan!”

Pendapat ini muncul karena kesalahpahaman mendasar. Mereka membandingkan dua hal yang tujuannya berbeda.

Bayangkan saja, membandingkan FPA dengan Story Points itu seperti membandingkan kilogram dengan “sulit dibawa”. Kedua pendekatan itu memang berbeda esensinya, satu objektif dan yang lain lebih subjektif.

• Story Points adalah ukuran upaya (effort) yang relatif dan spesifik untuk tim. Sebuah fitur mungkin bernilai “5 Poin” bagi tim senior Anda, tapi bisa jadi “8 Poin” bagi tim junior. Anda tidak bisa membandingkan Story Points antar tim atau antar perusahaan. Tujuannya adalah untuk perencanaan sprint jangka pendek.
• Function Points memberikan ukuran size yang absolut dan mudah dibandingkan. Misalnya, sebuah fitur berukuran 15 FP tetap sama, tak peduli siapa yang membangunnya atau berapa lama prosesnya berlangsung. Selain itu, Anda bisa menggunakannya untuk estimasi anggaran, benchmarking produktivitas antar proyek, serta pengukuran nilai proyek jangka panjang.

Keduanya bisa hidup berdampingan dengan damai. Tim development tetap menggunakan Story Points untuk mengukur kapasitas sprint mereka. Sementara itu, PMO (Project Management Office) atau manajemen senior menggunakan FPA untuk mengukur scope total proyek, memantau biaya per FP secara keseluruhan, dan membuat anggaran untuk tahun depan.

Kesimpulan: Menggunakan FPA untuk Estimasi Proyek IT yang Transparan

Di Indonesia, proyek implementasi ERP sering menghadapi kendala berupa ketidakpastian biaya dan pembengkakan scope (lingkup kerja). Kendala ini terutama muncul karena tuntutan kustomisasi yang tak bisa dihindari. Selain itu, metode estimasi tradisional yang subjektif sering gagal menyediakan prediktabilitas yang Anda butuhkan untuk investasi sebesar ERP.

Function Point Analysis (FPA) hadir sebagai “metode objektif” yang menjembatani kesenjangan antara persyaratan bisnis yang kualitatif dan estimasi proyek yang kuantitatif.

FPA menyediakan satuan ukuran fungsional yang standar (FP), sehingga manajer proyek, vendor, dan pemangku kepentingan bisnis bisa menyepakati ukuran pekerjaan lebih dulu. Selanjutnya, mereka pun dapat membahas upaya yang dibutuhkan secara lebih mendalam. Hasilnya, pendekatan ini mengubah “formula harga software” dari seni yang buram menjadi ilmu manajemen yang transparan.

Jika perusahaan Anda sedang atau akan menjalani transformasi digital melalui ERP, maka Anda sebaiknya mengadopsi FPA bukan sebagai latihan teknis biasa saja. Sebaliknya, langkah ini justru membawa Anda ke manajemen proyek yang lebih matang, terukur, dan prediktif. Pada akhirnya, FPA membantu Anda mengukur nilai yang benar-benar Anda kirimkan, bukan hanya upaya yang sudah Anda keluarkan.

FAQ (Pertanyaan Seputar Function Point Analysis ERP)

Berikut adalah beberapa pertanyaan umum yang sering muncul terkait Function Point Analysis:

1. Apa itu Function Point Analysis (FPA)? Function Point Analysis adalah metode terstandar untuk mengukur ukuran fungsional (seberapa “besar” software) dari perspektif pengguna. Metode ini menghitung fungsionalitas berdasarkan 5 komponen inti (ILF, EIF, EI, EO, EQ) dan menghasilkan angka “Function Point” (FP) yang independen dari teknologi.

2. Mengapa FPA lebih baik daripada menghitung Baris Kode (LOC)? Pertama-tama, FPA mengukur nilai fungsional, yaitu apa yang pengguna dapatkan dari sistem tersebut. Sedangkan, LOC justru fokus pada upaya teknis, seperti berapa banyak kode yang programmer tulis. Selain itu, FPA bersifat independen terhadap teknologi apa pun. Karena itu, Anda bisa membandingkan proyek Java, SAP, dan .NET dengan mudah menggunakan satu metrik yang sama, yaitu FP. Namun, LOC tidak mampu melakukan hal ini. Misalnya, membandingkan LOC antar bahasa pemrograman terasa seperti membandingkan apel dan durian – sama sekali tidak apple-to-apple.

3. Bagaimana FPA digunakan dalam proyek ERP? FPA sangat krusial untuk mengukur scope kustomisasi ERP. Ketika Anda meminta perubahan atau modul tambahan, FPA memberikan angka objektif (jumlah FP) untuk ukuran perubahan tersebut. Ini memungkinkan penetapan harga yang transparan (misalnya, biaya per FP) daripada estimasi jam kerja yang subjektif.

4. Apa bedanya FPA dengan Story Points di Agile/Scrum? Kedua metode ini memang punya tujuan yang berbeda. Misalnya, Function Point Analysis ERP mengukur ukuran (size) secara absolut, seperti dalam kilogram, sehingga tim bisa langsung membandingkannya antar proyek. Di sisi lain, Story Points menilai upaya (effort) secara relatif melalui kategori seperti “sulit dibawa”. Selain itu, Story Points berlaku khusus untuk satu tim saja, yang membuat penilaiannya tetap konsisten dari waktu ke waktu. Akhirnya, FPA memainkan peran kunci dalam penganggaran dan benchmarking, sementara Story Points lebih berguna untuk perencanaan sprint internal.