Prodi Bisnis Digital · FEB UNDIP

Perencanaan Sumber Daya Perusahaan

Pertemuan 7: Siklus Hidup ERP: Tahap Operasi dan Pemeliharaan

Setelah sistem ERP "hidup" (go-live), perjalanan sesungguhnya baru dimulai — bagaimana organisasi menjaga sistem tetap stabil, relevan, dan bernilai selama bertahun-tahun ke depan.

RPS minggu 8 · 2x50 menit

Bagian 1 dari 4

Dari Go-Live ke Operasi Rutin

Memahami posisi tahap operasi dalam siklus hidup ERP dan apa yang berubah begitu sistem mulai dipakai sehari-hari.

Rekap: Tiga Tahap Siklus Hidup ERP

Fase operasi & pemeliharaan bisa berlangsung 5-10 tahun hingga perusahaan mengganti sistem — jauh lebih panjang dari fase perencanaan dan implementasi yang biasanya hanya 6-18 bulan.

Tujuan Pembelajaran Pertemuan 7

Kognitif

Menjelaskan aktivitas utama tahap operasi ERP pasca go-live
Mengklasifikasikan jenis-jenis pemeliharaan sistem
Menghitung estimasi total cost of ownership (TCO) tahunan

Aplikatif

Menganalisis model dukungan pengguna (help desk tier)
Mengevaluasi kinerja sistem lewat metrik uptime
Mengidentifikasi tantangan nyata operasi ERP di Indonesia

Sub-CPMK: mahasiswa mampu menganalisis aktivitas operasi dan pemeliharaan ERP serta menghitung indikator biaya dan kinerjanya secara kuantitatif.

Go-Live dan Masa Stabilisasi (Hypercare)

Go-Live

Hari H

Sistem lama dimatikan, ERP mulai dipakai penuh

Titik ketika seluruh transaksi bisnis — penjualan, pembelian, gaji — mulai dijalankan lewat sistem ERP baru, bukan lagi sistem lama atau Excel.

Hypercare

2-8 minggu

Dukungan intensif pasca go-live

Periode kritis di mana tim proyek dan vendor masih siaga penuh untuk menangani bug, kebingungan pengguna, dan penyesuaian mendadak sebelum sistem dianggap "stabil".

Kesalahan umum: perusahaan membubarkan tim proyek terlalu cepat setelah go-live — padahal masa hypercare justru saat risiko kesalahan pengguna paling tinggi.

Aktivitas Utama Tahap Operasi Sehari-hari

Operasional Rutin

Menjalankan transaksi harian: input penjualan, proses payroll, rekonsiliasi stok, tutup buku bulanan.

Dukungan Pengguna

Menangani keluhan, error, dan pertanyaan "bagaimana cara..." dari ratusan pengguna lintas divisi.

Administrasi Sistem

Kelola hak akses pengguna baru/keluar, backup data harian, monitoring kapasitas server.

Berbeda dari tahap implementasi yang berfokus pada membangun sistem, tahap operasi berfokus pada menjaga sistem tetap berjalan setiap hari kerja.

Model Dukungan Pengguna: Struktur Tier Help Desk

Bagian 2 dari 4

Pemeliharaan Sistem ERP

Mengapa sistem yang sudah berjalan tetap butuh perbaikan, pembaruan, dan biaya rutin yang signifikan.

Empat Jenis Pemeliharaan Sistem (Taksonomi IEEE)

Jenis	Tujuan	Contoh Nyata
Corrective	Memperbaiki bug/kesalahan yang ditemukan	Laporan pajak salah hitung PPN, segera diperbaiki
Adaptive	Menyesuaikan sistem dengan perubahan lingkungan	Update tarif PPN efektif 11% (PMK 131/2024) ke modul keuangan
Perfective	Meningkatkan performa/fitur, bukan memperbaiki bug	Menambah dashboard analitik penjualan yang lebih cepat
Preventive	Mencegah masalah sebelum terjadi	Bersihkan data duplikat sebelum server penuh

Riset klasik menunjukkan perfective & adaptive menyumbang porsi terbesar biaya pemeliharaan jangka panjang — bukan corrective seperti dugaan kebanyakan orang.

Mari kita bedah taksonomi ini satu per satu karena sering tertukar. Corrective adalah yang paling intuitif, seperti dokter mengobati penyakit yang sudah muncul — bug ditemukan, langsung diperbaiki. Adaptive berbeda, ini terjadi ketika sistem harus menyesuaikan diri dengan perubahan di luar sistem itu sendiri, misalnya ketika pemerintah mengubah tarif PPN efektif menjadi 11 persen berdasarkan PMK 131/2024, modul keuangan ERP wajib diperbarui agar perhitungan pajak tetap benar. Perfective adalah peningkatan yang sifatnya proaktif, bukan karena ada yang rusak, tapi karena ingin lebih baik, seperti menambah dashboard yang lebih informatif. Preventive mirip servis berkala mobil — dilakukan sebelum ada gejala kerusakan. Callout di bawah penting karena sering jadi miskonsepsi mahasiswa: mereka kira sebagian besar biaya pemeliharaan untuk memperbaiki bug, padahal riset menunjukkan justru penyesuaian dan peningkatan yang paling banyak menyerap anggaran dalam jangka panjang.

Patch, Update, dan Upgrade: Apa Bedanya?

Patch

Kecil

Perbaikan tunggal, cepat

Menambal satu bug spesifik atau celah keamanan, biasanya dipasang tanpa henti operasional lama.

Minor Update

Sedang

Kumpulan perbaikan + fitur kecil

Rilis berkala (mis. tiap kuartal) berisi banyak patch sekaligus penambahan fitur ringan.

Major Upgrade

Besar

Ganti versi sistem

Perubahan arsitektur/versi besar (mis. SAP ECC ke S/4HANA), butuh proyek tersendiri & downtime terjadwal.

Major upgrade berisiko tinggi: butuh testing ulang, pelatihan ulang, dan window downtime yang harus direncanakan jauh-jauh hari — mirip proyek implementasi kecil.

Tiga istilah ini sering dipakai bergantian padahal skalanya sangat berbeda. Patch itu seperti menambal ban bocor, cepat dan minim gangguan. Minor update lebih mirip servis rutin bengkel, mengumpulkan beberapa perbaikan sekaligus perbaikan kecil, biasanya perusahaan seperti bank menjadwalkan ini di akhir pekan agar tidak mengganggu transaksi nasabah. Major upgrade jauh lebih besar, contohnya ketika perusahaan pengguna SAP ECC harus bermigrasi ke SAP S/4HANA — ini bukan sekadar instal update, melainkan proyek besar dengan testing menyeluruh dan pelatihan ulang seluruh pengguna, mirip seperti implementasi ERP dari awal lagi meski skalanya lebih kecil. Callout peringatan mengingatkan Anda bahwa banyak perusahaan menunda major upgrade bertahun-tahun karena takut risiko gangguan operasional, meski akibatnya sistem lama makin sulit didukung vendor.

Hitung dari Nol: Total Cost of Ownership (TCO) Tahunan ERP

Sebuah perusahaan retail menengah membayar lisensi ERP tahunan Rp 500 juta, biaya dukungan vendor 20% dari lisensi, infrastruktur cloud Rp 150 juta/tahun, dan tim internal 5 orang × Rp 12 juta/bulan.

Langkah	Perhitungan	Nilai
1. Lisensi tahunan	Sesuai kontrak vendor	Rp 500 juta
2. Dukungan vendor	20% × Rp 500 juta	Rp 100 juta
3. Infrastruktur cloud	Biaya hosting tahunan	Rp 150 juta
4. Tim internal (SDM)	5 × Rp 12 juta × 12 bulan	Rp 720 juta
5. Total TCO tahunan	500 + 100 + 150 + 720 juta	Rp 1.470 juta

Kesimpulan

~Rp1,47 M/tahun

SDM internal = 49% dari TCO — komponen terbesar, bukan lisensi

Mari hitung pelan-pelan seperti Anda sedang menyusun anggaran TI perusahaan. Langkah pertama, catat biaya lisensi tahunan sebesar Rp 500 juta sesuai kontrak vendor. Langkah kedua, biaya dukungan vendor biasanya dihitung sebagai persentase dari lisensi, di sini 20 persen dari Rp 500 juta menghasilkan Rp 100 juta. Langkah ketiga kita tambahkan biaya infrastruktur cloud Rp 150 juta per tahun, dan langkah keempat biaya tim internal yang dihitung dari 5 orang dikali gaji Rp 12 juta dikali 12 bulan sama dengan Rp 720 juta. Jumlahkan semuanya di langkah lima dan Anda mendapat total TCO tahunan Rp 1.470 juta atau sekitar Rp 1,47 miliar. Perhatikan kesimpulan di kotak biru — biaya SDM internal ternyata menyumbang hampir separuh total biaya, bukan biaya lisensi seperti yang sering dikira orang awam, ini alasan kenapa perusahaan perlu strategi retensi talenta ERP yang baik.

Coba Sendiri: Geser Komponen TCO Tahunan ERP

Ubah lisensi, persentase dukungan vendor, biaya infrastruktur, dan jumlah tim internal, lalu amati bagaimana total TCO tahunan dan komposisinya berubah.

Coba Sendiri: Ubah Skenario TCO

Diskusi berpasangan (5 menit): sebuah UMKM menengah hanya mampu bayar tim internal 2 orang (bukan 5), dan memilih hosting on-premise sehingga biaya cloud jadi Rp 0, diganti biaya listrik & server Rp 60 juta/tahun.

Tugas Anda

Hitung ulang total TCO tahunan skenario UMKM ini
Bandingkan strukturnya dengan contoh retail menengah tadi
Komponen mana yang sekarang paling dominan?

Petunjuk Perhitungan

Lisensi & dukungan vendor: asumsikan tetap sama
SDM: 2 × Rp 12 juta × 12 bulan
Infrastruktur: ganti dengan Rp 60 juta (server sendiri)

Change Management dan Pelatihan Berkelanjutan

Mengapa Pelatihan Tidak Berhenti di Go-Live

Karyawan baru terus masuk, perlu onboarding sistem
Fitur baru dari update perlu disosialisasikan
Pengguna lama sering lupa fitur yang jarang dipakai

Bentuk Dukungan Berkelanjutan

Modul e-learning internal & video tutorial singkat
Power user/champion di tiap divisi sebagai rujukan pertama
Sesi refresher training berkala (mis. tiap semester)

Perusahaan yang menghentikan pelatihan setelah go-live sering mengalami "regresi ke Excel" — karyawan diam-diam kembali memakai cara lama karena tidak paham fitur sistem baru.

Ini bagian yang sering diremehkan tapi krusial untuk keberhasilan jangka panjang. Bayangkan sebuah perusahaan distribusi yang setahun setelah go-live merekrut sepuluh staf gudang baru — kalau tidak ada program onboarding sistem yang jelas, mereka akan belajar sendiri secara serampangan dari senior yang mungkin juga belum paham benar. Konsep power user atau champion sangat efektif: satu orang di setiap divisi dilatih lebih mendalam dan menjadi rujukan pertama sebelum masalah dieskalasi ke help desk, mengurangi beban tim IT secara signifikan. Fenomena "regresi ke Excel" pada callout ini nyata terjadi di banyak UMKM dan bahkan perusahaan besar di Indonesia — karyawan yang frustrasi dengan sistem baru diam-diam kembali mencatat di spreadsheet pribadi, yang justru merusak tujuan integrasi data yang menjadi alasan awal investasi ERP.

Bagian 3 dari 4

Mengukur Kinerja Sistem yang Berjalan

Uptime, waktu respons, dan indikator lain yang menentukan apakah sistem ERP benar-benar melayani bisnis dengan baik.

Metrik Kinerja Operasional Sistem ERP

Uptime

Persentase waktu sistem aktif

Response Time

ms/detik

Kecepatan sistem merespons transaksi

Ticket Resolution

Jam/Hari

Kecepatan tim menutup keluhan pengguna

Ketiga metrik ini biasanya dituangkan dalam Service Level Agreement (SLA) — kontrak formal target layanan antara divisi TI/vendor dan unit bisnis pengguna.

Ketiga metrik ini adalah bahasa umum yang dipakai tim IT operasional di mana pun, termasuk perusahaan seperti Bank Mandiri atau Garuda Indonesia yang sangat bergantung pada sistem yang harus selalu aktif. Uptime mengukur seberapa sering sistem tersedia untuk dipakai, response time mengukur seberapa cepat sistem merespons ketika kasir menekan tombol "simpan transaksi", dan ticket resolution mengukur seberapa cepat tim IT menyelesaikan keluhan setelah dilaporkan. Ketiganya biasanya tidak sekadar diukur untuk internal, tapi dituangkan dalam SLA — kontrak formal yang menetapkan target, misalnya "uptime minimal 99,9%" — dan jika target ini tidak tercapai, bisa ada konsekuensi kontraktual dengan vendor. Slide berikutnya akan mengajak Anda menghitung sendiri apakah sebuah sistem memenuhi SLA uptime-nya.

Hitung dari Nol: Uptime vs Target SLA

Dalam sebulan (30 hari), sistem ERP sebuah perusahaan logistik mencatat downtime 3,6 jam karena maintenance darurat. Target kontrak SLA vendor adalah uptime 99,9%.

Langkah	Perhitungan	Nilai
1. Total waktu operasional	30 hari × 24 jam	720 jam
2. Downtime tercatat	Dari log insiden	3,6 jam
3. Uptime aktual	(720 − 3,6) ÷ 720 × 100	99,5%
4. Batas downtime SLA 99,9%	720 × 0,1%	0,72 jam (≈43 menit)
5. Status SLA	3,6 jam > 0,72 jam	Tidak tercapai (breach)

Makna Praktis

Gap 2,88 jam

Uptime 99,5% terdengar tinggi, tapi melanggar SLA 99,9% — berisiko penalti kontrak vendor

Mari kita hitung bersama, langkah pertama kita tentukan dulu total waktu operasional dalam sebulan, yaitu 30 hari dikali 24 jam sama dengan 720 jam. Langkah kedua kita catat downtime yang benar-benar terjadi, yaitu 3,6 jam dari log insiden. Langkah ketiga kita hitung uptime aktual dengan mengurangi total jam dengan downtime, dibagi total jam, dikali 100, hasilnya 99,5 persen — angka yang sekilas terlihat sangat bagus. Tapi langkah keempat inilah yang penting, kita hitung berapa batas downtime yang diperbolehkan jika target SLA 99,9 persen, yaitu 720 dikali 0,1 persen sama dengan 0,72 jam atau sekitar 43 menit saja. Karena downtime aktual 3,6 jam jauh melebihi batas 0,72 jam, di langkah lima kita simpulkan SLA ini gagal tercapai atau breach. Inilah kenapa "99 persen" itu menipu — dalam bisnis skala besar seperti maskapai atau perbankan, selisih 0,1 persen saja bisa berarti jutaan rupiah kerugian atau ribuan transaksi terganggu.

Coba Sendiri: Uji Batas Downtime terhadap Target SLA

Ubah jumlah jam downtime dan target uptime SLA, lalu amati apakah sistem masih dalam batas kontrak atau sudah "breach".

Audit dan Kepatuhan Sistem Berkelanjutan

Mengapa Perlu Diaudit Terus-menerus

Hak akses bisa "menumpuk" seiring rotasi jabatan karyawan
Kustomisasi tak terdokumentasi menumpuk seiring waktu
Regulasi (pajak, pelaporan keuangan) terus berubah

Aktivitas Kepatuhan Rutin

Review hak akses (access review) berkala
Audit jejak transaksi (audit trail) untuk laporan keuangan
Uji kepatuhan pajak: PPN efektif 11%, PPh Badan 22%

Topik keamanan & internal control ini akan kita bahas lebih mendalam pada pertemuan tentang ISACA dan kontrol internal — hari ini cukup pahami bahwa kepatuhan bukan aktivitas sekali jalan.

Poin penting di slide ini adalah bahwa kepatuhan sistem bukan pekerjaan yang selesai saat go-live, melainkan aktivitas yang berulang selamanya. Bayangkan seorang karyawan yang dulunya staf keuangan lalu dipromosikan menjadi manajer pemasaran — jika hak aksesnya di sistem ERP tidak pernah direview ulang, dia masih bisa mengubah data keuangan meski sudah tidak relevan dengan pekerjaannya, ini celah keamanan serius yang sering ditemukan auditor. Demikian juga dengan perubahan regulasi seperti tarif PPN efektif 11 persen sesuai PMK 131/2024 atau PPh Badan 22 persen, sistem ERP harus terus disesuaikan agar laporan pajak perusahaan tetap patuh hukum. Slide ini sengaja menjadi jembatan ke materi keamanan sistem dan kontrol internal berbasis kerangka ISACA yang akan kita bahas mendalam nanti — untuk sekarang cukup Anda pahami bahwa operasi, pemeliharaan, dan kepatuhan berjalan beriringan terus-menerus.

Tantangan Nyata Tahap Operasi & Pemeliharaan

Technical Debt
Kustomisasi darurat yang "sementara" saat go-live sering tidak pernah dirapikan, menumpuk jadi beban teknis bertahun-tahun kemudian.

Vendor Lock-in
Semakin lama dipakai dan dikustomisasi, semakin mahal dan berisiko biaya untuk berpindah ke sistem/vendor lain.

Shadow IT
Karyawan diam-diam pakai spreadsheet/aplikasi lain karena fitur ERP dianggap ribet — data jadi terfragmentasi lagi.

Obsolescence
Versi sistem yang tidak pernah di-upgrade akhirnya kehilangan dukungan resmi vendor (end-of-life).

Keempat tantangan ini adalah yang paling sering muncul dalam studi kasus kegagalan ERP jangka panjang, bukan saat implementasi tapi bertahun-tahun setelahnya. Technical debt terjadi ketika tim proyek buru-buru menambal masalah saat go-live dengan solusi sementara, misalnya laporan manual di luar sistem, dan solusi sementara itu tidak pernah dirapikan sampai bertahun-tahun kemudian menyulitkan tim baru yang tidak paham konteksnya. Vendor lock-in adalah dilema klasik — perusahaan seperti maskapai atau bank besar yang sudah kustomisasi sistemnya selama sepuluh tahun akan sangat sulit dan mahal untuk pindah ke vendor lain, meski vendor lama menaikkan harga secara signifikan. Shadow IT sering terjadi di UMKM yang baru migrasi ERP — karyawan merasa Excel lebih cepat dan diam-diam kembali memakainya, merusak integrasi data yang menjadi tujuan awal investasi. Obsolescence menjadi masalah serius ketika vendor mengumumkan end-of-life untuk versi lama, memaksa perusahaan melakukan major upgrade mendesak dengan anggaran yang belum siap.

Studi Kasus: Operasi ERP di Perusahaan Indonesia

BUMN Sektor Energi

Perusahaan energi besar menjalankan SAP untuk operasi multi-anak usaha selama lebih dari satu dekade, dengan tim internal ratusan orang khusus menangani dukungan & pemeliharaan lintas unit bisnis.

Perusahaan Ritel Nasional

Jaringan ritel modern melakukan major upgrade ERP setiap 5-7 tahun untuk mengikuti pertumbuhan jumlah gerai, disertai pelatihan ulang ribuan karyawan toko di seluruh Indonesia.

UMKM Manufaktur Menengah

UMKM manufaktur yang migrasi ke ERP berbasis cloud memilih paket dukungan vendor penuh (managed service) karena tidak mampu membangun tim IT internal besar.

Bank Digital Baru

Bank digital menargetkan uptime 99,95% pada sistem inti karena satu menit downtime langsung terlihat nasabah di aplikasi mobile — SLA jauh lebih ketat dari sektor lain.

Keempat studi kasus ini menggambarkan bahwa strategi operasi dan pemeliharaan sangat bergantung pada skala dan sektor bisnis. BUMN energi besar mampu membangun tim internal ratusan orang karena skala operasinya sangat besar dan kompleks lintas anak usaha. Perusahaan ritel nasional dengan ribuan gerai punya tantangan berbeda yaitu pelatihan ulang massal setiap kali ada upgrade besar, bayangkan melatih ulang kasir di seribu toko dalam waktu terbatas. UMKM manufaktur menengah biasanya memilih jalan pragmatis dengan menyerahkan sepenuhnya pemeliharaan ke vendor lewat skema managed service karena tidak realistis membangun tim IT sendiri. Bank digital menjadi contoh ekstrem soal pentingnya uptime, karena nasabah modern langsung mengeluh di media sosial jika aplikasi mobile banking down walau hanya beberapa menit, sehingga target SLA mereka jauh lebih ketat dibanding sektor manufaktur misalnya.

Rangkuman, Tugas, dan Pertemuan Berikutnya

5 Takeaway Utama

Tahap operasi & pemeliharaan berlangsung jauh lebih lama dari implementasi — 5-10 tahun.
Empat jenis pemeliharaan: corrective, adaptive, perfective, preventive — masing-masing tujuan berbeda.
TCO tahunan bisa mencapai miliaran rupiah, dengan SDM internal sering jadi komponen terbesar.
Uptime tinggi belum tentu memenuhi SLA — selisih 0,1% bisa berarti jam kerugian nyata.
Tantangan jangka panjang: technical debt, vendor lock-in, shadow IT, obsolescence.

Tugas Individu (kumpul minggu depan)

Wawancara singkat/cari studi kasus 1 organisasi pengguna ERP
Identifikasi jenis pemeliharaan yang paling sering mereka lakukan
Estimasi TCO tahunan mereka dengan pola perhitungan hari ini

Preview Pertemuan 8

Modul Financial Management dalam ERP
Integrasi General Ledger, AP/AR, dan pelaporan keuangan
Studi kasus: konfigurasi modul keuangan perusahaan Indonesia

Mari kita rangkum perjalanan hari ini sebelum Anda mengerjakan tugas. Anda sudah memahami bahwa tahap operasi dan pemeliharaan adalah fase terpanjang dalam siklus hidup ERP, dengan empat jenis pemeliharaan yang punya tujuan berbeda, dan biaya tahunan yang bisa mencapai miliaran rupiah untuk perusahaan skala menengah. Anda juga sudah berlatih menghitung sendiri TCO dan uptime, dua keterampilan kuantitatif yang langsung relevan jika Anda bekerja di tim IT atau business analyst kelak. Untuk tugas minggu depan, silakan cari satu organisasi nyata — bisa tempat magang, bisnis keluarga, atau hasil riset internet tentang perusahaan terbuka di BEI — dan terapkan pola perhitungan yang sudah kita pelajari hari ini. Pertemuan depan kita mulai masuk ke modul fungsional pertama ERP, yaitu Financial Management, tempat semua konsep operasi yang kita bahas hari ini akan Anda lihat diterapkan secara konkret pada modul keuangan. Sampai jumpa minggu depan!