Banyak proyek ERP tidak tersendat karena perangkat lunaknya, melainkan karena keputusan yang menggantung. Divisi keuangan dan gudang berbeda pendapat soal alur penerimaan barang, dan perdebatan itu baru selesai tiga minggu kemudian. Vendor menunggu, konsultan menganggur, dan jadwal go-live mundur tanpa ada yang merasa bertanggung jawab. Di sinilah tata kelola proyek ERP berperan: kerangka yang menetapkan siapa memutuskan apa, kapan, dan berdasarkan informasi apa.
Isu ini makin relevan karena proyek ERP di perusahaan menengah-besar Indonesia hampir selalu melibatkan banyak pihak sekaligus: direksi, beberapa divisi, tim IT internal, vendor perangkat lunak, partner implementasi, dan kadang integrator pihak ketiga. Tanpa struktur yang jelas, setiap pihak bekerja dengan asumsinya masing-masing.
Artikel ini membahas komponen tata kelola proyek (project governance) untuk implementasi ERP, cara menerapkannya secara praktis, dan kesalahan yang sering membuat struktur di atas kertas tidak berjalan di lapangan.
Apa itu Tata Kelola Proyek ERP?
Tata kelola proyek ERP adalah kumpulan struktur, peran, hak keputusan, forum, dan mekanisme kontrol yang memastikan proyek tetap selaras dengan tujuan bisnis. Ia menjawab pertanyaan seperti: siapa yang boleh menyetujui perubahan ruang lingkup, ke mana isu dibawa bila tim tidak sepakat, dan kriteria apa yang harus dipenuhi sebelum proyek lanjut ke fase berikutnya.
Tata kelola berbeda dengan manajemen proyek. Manajemen proyek mengurus eksekusi harian: jadwal, tugas, dan sumber daya. Tata kelola menetapkan arah, batas wewenang, dan cara keputusan diambil. Kerangka yang dikenal luas seperti PRINCE2 pun memisahkan lapisan "mengarahkan" (dewan proyek) dari lapisan "mengelola" (manajer proyek). Prinsipnya sederhana: pihak yang menjalankan pekerjaan tidak seharusnya menjadi satu-satunya penilai atas kemajuannya sendiri.
Mengapa Tata Kelola Proyek ERP Penting bagi Bisnis
ERP menyentuh hampir semua fungsi: penjualan, pembelian, gudang, produksi, keuangan, hingga SDM. Setiap keputusan desain berarti kompromi antardivisi. Kepala gudang ingin proses penerimaan barang cepat, sementara keuangan ingin setiap penerimaan tercocokkan dengan PO dan faktur. Kompromi seperti ini butuh pemegang wewenang di atas level divisi.
Lemahnya tata kelola sering berada di balik berbagai penyebab kegagalan implementasi ERP, dari jadwal molor hingga sistem yang akhirnya tidak dipakai. Dampaknya terasa pada tiga hal:
- Biaya waktu tunggu. Bila kontrak partner berbasis hari orang (man-day), setiap minggu keputusan tertunda adalah biaya yang tetap berjalan tanpa kemajuan. Pada kontrak harga tetap, keterlambatan biasanya berujung negosiasi perubahan kontrak.
- Ruang lingkup yang membengkak. Tanpa prosedur perubahan, permintaan "sekalian ditambah" menumpuk dan menggerus anggaran.
- Akuntabilitas yang kabur. Saat proyek terlambat, vendor dan tim internal saling menunjuk karena tidak ada catatan siapa memutuskan apa.
Bagi perusahaan terbuka atau BUMN yang memiliki komite audit dan satuan pengawasan internal, jejak keputusan yang terdokumentasi juga memudahkan pemeriksaan atas proyek bernilai besar.
Komponen Utama Tata Kelola Proyek
Struktur tata kelola tidak harus rumit. Yang penting, setiap komponen di bawah ini punya pemilik yang jelas dan benar-benar dijalankan.
Struktur organisasi proyek dan peran kunci
Tabel berikut merangkum peran yang umum dalam proyek ERP skala menengah-besar. Nama jabatannya bisa berbeda, tetapi fungsinya sebaiknya tetap ada.
| Peran | Biasanya diisi oleh | Tanggung jawab utama |
|---|---|---|
| Project Sponsor | Anggota direksi, misalnya Direktur Keuangan atau Direktur Operasional | Pemilik hasil bisnis; memutuskan isu yang tidak selesai di bawah; menjaga anggaran dan prioritas |
| Steering Committee | Sponsor, kepala divisi terdampak, perwakilan senior partner | Menyetujui ruang lingkup, perubahan besar, kelulusan fase, dan keputusan go-live |
| Project Manager internal | Manajer senior yang dibebastugaskan sebagian atau penuh | Mengoordinasikan tim internal, menjaga jadwal, menyiapkan bahan keputusan |
| Project Manager partner | Vendor atau partner implementasi | Mengelola konsultan, deliverable kontrak, dan risiko teknis |
| Process Owner | Kepala divisi atau manajer proses | Memutuskan desain proses di areanya dan menandatangani hasil pengujian |
| Key User | Staf senior yang memahami operasional | Menjelaskan kebutuhan, menguji sistem, melatih rekan kerja |
| PMO / Quality Assurance | Tim internal atau pihak independen (untuk proyek besar) | Memantau kepatuhan proses, memvalidasi laporan status, mengawal quality gate |
Hak keputusan dan jalur eskalasi
Struktur saja tidak cukup bila tidak jelas siapa boleh memutuskan apa. Buat matriks hak keputusan sederhana. Misalnya, konfigurasi yang masih dalam ruang lingkup diputuskan process owner. Pergeseran jadwal kecil yang tidak memengaruhi go-live diputuskan kedua project manager. Perubahan ruang lingkup, anggaran, atau tanggal go-live hanya boleh diputuskan steering committee.
Tetapkan juga batas waktu eskalasi. Sebagai ilustrasi, isu yang tidak selesai di level tim dalam tiga hari kerja otomatis naik ke project manager, lalu ke sponsor. Batas waktu ini mencegah isu "parkir" berminggu-minggu karena tidak ada yang mau mengambil risiko memutuskan.
Forum dan ritme rapat
Setiap forum harus punya tujuan dan keluaran yang jelas, bukan sekadar rutinitas. Pola yang umum dipakai:
- Rapat tim harian atau dua kali seminggu: membahas hambatan teknis dan tugas yang terlambat.
- Rapat project manager mingguan (internal dan partner): memperbarui jadwal dan daftar isu, serta menyiapkan bahan keputusan.
- Steering committee bulanan, dipercepat menjadi dua mingguan menjelang pengujian dan go-live: forum untuk mengambil keputusan, bukan sekadar menerima presentasi.
Sesuaikan ritme ini dengan fase proyek. Artikel tentang timeline implementasi ERP yang realistis membahas tahapan yang biasanya menentukan kapan intensitas rapat perlu dinaikkan.
Pengendalian ruang lingkup dan change request
Setiap permintaan di luar baseline yang disepakati harus masuk sebagai change request (CR) tertulis. Alurnya: pengajuan oleh process owner, analisis dampak oleh partner (biaya, waktu, risiko, dan apakah kebutuhan bisa dipenuhi fitur standar), keputusan sesuai matriks wewenang, lalu pembaruan baseline. Prinsip fit-to-standard membantu di sini: setiap kustomisasi harus dibuktikan kebutuhannya, bukan sekadar meniru cara kerja sistem lama.
Manajemen risiko, isu, dan ketergantungan
Gunakan satu log terpusat yang sering disebut RAID log (Risks, Assumptions, Issues, Dependencies). Setiap entri punya pemilik, tanggal target, dan status. Beberapa risiko khas proyek ERP di Indonesia patut dicatat sejak awal: ketersediaan key user saat tutup buku akhir tahun, periode libur Lebaran, perubahan aturan perpajakan, serta ketergantungan pada sistem lain seperti aplikasi HR, e-commerce, atau perbankan.
Quality gate antarfase
Quality gate adalah titik pemeriksaan formal sebelum proyek lanjut ke fase berikutnya. Contohnya: dokumen desain proses sudah ditandatangani process owner sebelum konfigurasi dimulai, data hasil uji migrasi sudah direkonsiliasi sebelum pengujian pengguna, dan hasil user acceptance testing (UAT) tidak menyisakan isu kritis sebelum go-live diputuskan. Gate yang tegas mencegah masalah di fase awal terbawa dan membesar di fase akhir.
Langkah Praktis Menerapkan Tata Kelola Proyek
- Susun project charter sebelum kickoff. Tuliskan tujuan bisnis yang terukur, ruang lingkup, anggaran, dan sponsor. Charter menjadi rujukan saat muncul perdebatan prioritas.
- Petakan peran dengan RACI. Untuk setiap deliverable utama, tentukan siapa yang Responsible, Accountable, Consulted, dan Informed. Pastikan hanya ada satu "A" per deliverable.
- Masukkan tata kelola ke kontrak. Kewajiban partner menghadiri steering committee, format laporan status, dan prosedur CR sebaiknya tertulis di statement of work, bukan hanya disepakati lisan.
- Bebaskan waktu key user secara resmi. Alokasi waktu, misalnya setengah hari kerja atau penuh pada fase tertentu, perlu disetujui atasan mereka dan tercermin pada target kerja, bukan sekadar tertulis di rencana proyek.
- Standarkan laporan status. Pakai format ringkas dengan indikator merah-kuning-hijau (RAG) untuk jadwal, anggaran, ruang lingkup, dan risiko, disertai daftar keputusan yang dibutuhkan dari steering committee.
- Dokumentasikan setiap keputusan. Simpan notulen dan log keputusan yang mencatat tanggal, pemutus, alasan, serta dampaknya.
- Tinjau ulang struktur di setiap fase. Kebutuhan tata kelola saat fase desain berbeda dengan saat hypercare. Sesuaikan anggota forum dan frekuensinya.
Kesalahan Umum yang Perlu Dihindari
- Steering committee yang seremonial. Rapat diisi presentasi kemajuan tanpa satu pun keputusan. Kirim bahan beberapa hari sebelumnya dan buka rapat dengan daftar keputusan yang dibutuhkan.
- Sponsor yang didelegasikan terlalu ke bawah. Bila sponsor tidak punya wewenang atas semua divisi terdampak, konflik antardivisi tidak akan pernah tuntas.
- Bergantung sepenuhnya pada project manager partner. Partner mengelola konsultannya, tetapi tidak bisa memaksa divisi internal Anda mengambil keputusan.
- Laporan yang selalu hijau. Dalam budaya kerja yang hierarkis, kabar buruk sering ditahan agar tidak terkesan gagal. Jadikan pelaporan risiko secara dini sebagai hal yang dihargai, bukan dihukum.
- Change request lisan. Kata "sekalian saja" di rapat informal adalah awal ruang lingkup yang membengkak.
- Mengabaikan sisi manusia. Struktur yang rapi tetap gagal bila pengguna menolak sistem baru. Padukan tata kelola dengan manajemen perubahan organisasi yang terencana.
Pertanyaan yang Sering Diajukan
Apa beda tata kelola proyek dan manajemen proyek ERP?
Manajemen proyek mengurus eksekusi: jadwal, tugas, dan sumber daya. Tata kelola proyek menetapkan arah, wewenang, dan cara keputusan diambil, sekaligus mengawasi apakah eksekusi masih sesuai tujuan bisnis.
Siapa yang paling tepat menjadi project sponsor?
Anggota direksi yang paling berkepentingan atas manfaat bisnis ERP dan punya wewenang atas divisi-divisi yang terdampak. Di banyak perusahaan, peran ini diisi Direktur Keuangan atau Direktur Operasional. Yang terpenting, sponsor bersedia meluangkan waktu dan mengambil keputusan sulit.
Seberapa sering steering committee perlu bertemu?
Umumnya sebulan sekali selama fase desain dan konfigurasi, lalu dua minggu sekali menjelang pengujian dan go-live. Di luar jadwal rutin, sediakan mekanisme rapat darurat untuk keputusan yang tidak bisa menunggu.
Apakah perusahaan menengah perlu PMO khusus?
Tidak selalu. Untuk proyek dengan ruang lingkup terbatas, fungsi PMO bisa dirangkap project manager internal. PMO atau quality assurance independen lebih relevan bila proyek mencakup banyak entitas, lokasi, atau integrasi yang kompleks.
Apakah tata kelola berhenti setelah go-live?
Tidak. Selama masa hypercare, forum keputusan tetap dibutuhkan untuk memprioritaskan perbaikan. Setelah itu, steering committee proyek biasanya beralih menjadi forum tata kelola sistem yang mengatur permintaan perubahan dan pengembangan lanjutan.
Kesimpulan
Tata kelola proyek ERP bukan birokrasi tambahan. Ia adalah cara memastikan setiap keputusan penting diambil oleh orang yang tepat, tepat waktu, dan terdokumentasi. Struktur peran yang jelas, matriks hak keputusan, forum yang menghasilkan keputusan, prosedur change request, log risiko, dan quality gate menjadi fondasi agar proyek tetap terkendali dari kickoff hingga hypercare.
Sebagai penyedia layanan implementasi ERP, system integration, dan IT consulting, Solvera dapat membantu merancang struktur tata kelola yang sesuai dengan skala dan budaya organisasi Anda. Bila Anda sedang menyiapkan proyek ERP dan ingin memetakan peran, wewenang, serta forum keputusannya sebelum kickoff, silakan diskusikan rancangan tata kelola proyek Anda bersama tim konsultan kami.