Setiap project SAP punya ceritanya sendiri. Ada yang berjalan mulus, ada yang penuh drama. Tapi kalau kamu pernah terlibat dalam project SAP, pasti paham satu hal: tidak ada project yang benar-benar mulus! Selalu ada kejutan, kesalahpahaman, meeting yang tak berkesudahan, dan tentunya momen-momen lucu yang tak terlupakan. Berikut adalah kisah nyata yang sering terjadi di dunia project SAP!
Blueprint Sudah Fix? Tunggu Dulu!
Di awal project, semua tampak rapi dan terstruktur. Meeting blueprint berjalan lancar, user setuju dengan semua yang kita dokumentasikan. Saya sebagai Functional SAP HCM merasa sudah menang.
Tapi…
Dua bulan kemudian, saat konfigurasi hampir selesai, user datang dengan wajah polos.
User: “Mas, kayaknya ada yang lupa. Kita butuh field tambahan di infotype 0008 buat tunjangan baru.”
Functional: “Tunjangan baru? Kok nggak disebut di blueprint?”
User: “Ya waktu itu belum kepikiran, baru inget sekarang.”
Functional: (menahan emosi, menarik napas panjang)
Hasilnya? Blueprint yang katanya “FIX” ternyata bisa berubah kapan saja. Ini kejadian klasik di project SAP. Selalu ada perubahan di tengah jalan, dan Functional harus siap menghadapi revisi mendadak yang membuat timeline makin mundur.
ABAP vs Functional: Perang Tanpa Akhir
Saya pernah mengira tim Functional dan tim ABAP itu ibarat tim sepak bola yang saling bahu-membahu mencetak gol. Nyatanya? Kadang lebih seperti dua kubu yang siap berperang.
Functional kirimkan spesifikasi:
“Program harus bisa mengambil data absensi dari IT2001 dan IT2002, kemudian dihitung dengan formula XYZ.”
Seminggu kemudian, hasil coding siap testing. Saya coba jalankan transaksi. ERROR.
Functional: “Mas, kenapa data absensi nggak masuk ke payroll?”
ABAPer: “Lho, di spesifikasi nggak ada instruksi buat baca IT2011.”
Functional: “Tapi kan logika bisnisnya sudah jelas?”
ABAPer: “Jelas di kepala Mas aja, nggak di spesifikasi.”
Akhirnya, revisi spesifikasi. Functional belajar satu hal: ABAP bukan cenayang, mereka nggak bisa membaca pikiran kita. Kalau mau program bekerja sesuai keinginan, harus jelas tertulis di spesifikasi.
Deadline Sudah Dekat, Bugs Masih Banyak
H-7 sebelum Go-Live. Tim Functional dan ABAP sudah kerja rodi, testing bertubi-tubi. Semua sistem terlihat baik-baik saja. Sampai akhirnya…
User: “Mas, ini data lembur kok nggak masuk ke slip gaji?”
Functional: (mulai panik) “Sebentar, saya cek.”
Saat debugging, baru ketahuan kalau ada skenario yang terlewat. ABAPer sudah mulai pucat, Functional mulai berkeringat, user mulai protes. Solusi?
- Cari siapa yang salah (meski ujung-ujungnya tetap harus dikerjakan Functional dan ABAP).
- Cari workaround cepat biar sistem tetap jalan.
- Siapkan mental untuk revisi sistem setelah Go-Live.
Di project SAP, deadline itu bukan garis finish. Seringnya, setelah Go-Live, kita baru sadar ada fitur yang terlewat dan harus segera diperbaiki.
Go-Live: Momen Penuh Adrenalin
Hari yang ditunggu-tunggu akhirnya tiba. Semua sudah siap, user mulai menggunakan sistem SAP untuk pertama kalinya. Kami, tim project, duduk tegang di depan laptop, memantau sistem seperti trader saham melihat grafik turun-naik.
Lalu…
📢 User panik: “Mas! Kok saya nggak bisa approve cuti karyawan?”
📢 Payroll tim protes: “Ini kenapa BPJS nggak masuk ke slip gaji?”
📢 IT menelpon: “Database overload, server hampir mati!”
Dalam satu hari, semua bisa kacau. Tapi di sinilah tantangannya. Tim project harus siap jadi pahlawan, menemukan solusi dengan cepat, dan menghadapi user dengan wajah tetap tenang meskipun di dalam hati sudah meledak-ledak.
Dan akhirnya, setelah berjam-jam debugging, sistem kembali normal. Semua orang bisa bernapas lega. Functional dan ABAP saling pandang, tersenyum, lalu berkata:
“Kapan kita liburan?”
Jawabannya? “Setelah post-Go-Live support selesai.” 😂
Pelajaran Berharga dari Project SAP
Dari semua kekacauan yang terjadi di project, ada banyak pelajaran yang bisa diambil:
✅ Blueprint harus super detail. Jangan ada ruang untuk asumsi. Kalau bisa ditulis, tulis! Jangan hanya di kepala.
✅ Functional dan ABAP harus sering diskusi. Jangan hanya lewat email, tapi benar-benar duduk bersama, membahas logika bisnis dengan jelas.
✅ User suka berubah pikiran. Jangan kaget kalau mereka tiba-tiba ingin fitur baru. Antisipasi sejak awal dan siapkan buffer waktu di timeline.
✅ Testing itu harga mati. Lebih baik menemukan bug di internal testing daripada saat user sudah mulai memakai sistem.
✅ Go-Live bukan akhir. Justru di sinilah perjuangan sebenarnya dimulai. Setelah user pakai sistem, barulah kita tahu mana yang masih kurang dan butuh diperbaiki.
Di project SAP, ada tawa, ada stres, ada lembur, ada kelelahan. Tapi yang pasti, ada juga kepuasan luar biasa saat sistem akhirnya berjalan sesuai harapan. Dan itu adalah hal yang membuat semua perjuangan ini worth it.
“Selamat berjuang, para pejuang Mandys! Terus maju dan jangan menyerah!”
Bagaimana pengalamanmu dalam project implementasi SAP? Yuk, bagikan ceritamu di kolom komentar! Jangan lupa klik Like jika kamu pernah mengalami tantangan serupa!