Kualitas Data Adalah Risiko Nomor Satu dalam Proyek ERP — Berikut Cara Memasukkannya ke dalam Daftar Risiko

Ketika steering committee ERP Anda terakhir kali meninjau project risk register, apakah kualitas data ada di dalamnya — dengan owner yang ditunjuk, skor berbasis bukti dan rencana mitigasi yang didanai? Atau hanya menjadi bullet point di catatan slide seseorang, yang dikategorikan sebagai "hal-hal yang akan dibereskan oleh tim migrasi"? Bagi sebagian besar pemimpin IT, kejujuran memaksa kita memilih jawaban kedua. Dan kesenjangan antara seberapa besar kualitas data mengancam program ERP dan seberapa formal risiko tersebut dikelola menjelaskan sebagian besar keterlambatan, pembengkakan anggaran dan pemadaman masalah setelah go-live yang terjadi.

Masalahnya jarang terletak pada awareness. Setiap pemimpin IT yang berpengalaman tahu data yang kotor merugikan migrasi. Masalahnya adalah translation: kualitas data dibahas dalam bahasa teknis ("material master perlu dilakukan cleansing") sementara steering committee mengambil keputusan dalam bahasa risiko (probability, impact, owner, mitigation, cost of inaction). Tutup kesenjangan translation tersebut, dan kualitas data akhirnya mendapatkan perhatian — dan anggaran — yang selama ini memang layak didapatkannya.

Gelombang Migrasi yang Didorong Deadline Mengungkap Kelemahan Lama

Konteksnya membuat hal ini menjadi semakin mendesak. Dengan berakhirnya mainstream maintenance SAP untuk ECC yang mendekati tahun 2027, ribuan organisasi — termasuk sebagian besar perusahaan asset-intensive di Australia dan Asia Tenggara — berada di tengah migrasi S/4HANA atau perpindahan yang lebih luas ke cloud ERP. Para analis telah memperingatkan selama beberapa tahun bahwa gelombang migrasi semakin padat: semakin dekat deadline, semakin banyak proyek berjalan secara paralel, semakin langka sumber daya implementasi yang terampil, dan semakin kecil ruang bagi setiap program untuk menyerap kejutan.

Dalam konteks tersebut, satu pola dari dua dekade sejarah ERP menjadi semakin penting: post-mortem industri secara konsisten menempatkan masalah data sebagai salah satu penyebab utama keterlambatan ERP dan pembengkakan anggaran — sering kali di atas software defects dan integration problems. Pola ini stabil di berbagai vendor dan industri, yang menunjukkan bahwa masalah tersebut bersifat struktural, bukan insidental. Migrasi tidak tersendat karena sistem baru tidak dapat menampung data; migrasi tersendat karena data lama tidak dapat bertahan dalam perjalanan tersebut. Duplicate material records, incomplete descriptions dan inconsistent classifications yang diam-diam dapat ditoleransi oleh instance ECC berusia dua puluh tahun berubah menjadi blocking defects saat program migrasi mulai melakukan mapping, validation dan loading terhadap data tersebut.

Jika dibaca sebagai news analysis, implikasinya bagi para pemimpin IT sangat jelas: dalam pasar migrasi yang semakin padat, risiko yang dapat Anda hilangkan lebih awal memiliki nilai yang jauh lebih besar. Dan tidak ada risiko yang lebih mudah — dan lebih murah — untuk dihilangkan lebih awal daripada kualitas data.

Mengapa Kualitas Data Mendapat Posisi Teratas dalam Risk Register

Sebuah risiko mendapatkan posisinya dalam register melalui perhitungan probability times impact, dan kualitas material master mendapatkan skor yang sangat tinggi pada keduanya.

Mulai dari probability. Tidak seperti kebanyakan project risks, ini bukan pertanyaan tentang apakah sesuatu mungkin salah — defect tersebut sudah ada, hari ini, di production system Anda. Assessment terhadap material master di industri mining, oil and gas, power generation dan manufacturing secara rutin menemukan duplication rates sebesar 10–20 per cent, description completeness yang jauh di bawah persyaratan migration validation rules, dan classification coverage yang paling baik pun masih tidak merata. Jika organisasi Anda belum pernah melakukan assessment formal terhadap material master, probability bahwa data tersebut mengandung migration-blocking defects bukanlah "possible". Probability tersebut mendekati pasti.

Impact adalah bagian di mana angkanya menjadi serius. Data defects yang ditemukan selama migration testing memaksa rework cycles yang menghabiskan sumber daya paling langka dalam sebuah program ERP: window of availability functional experts dan implementation consultants. Setiap data load yang gagal mendorong cutover rehearsals mundur; setiap rehearsal yang mundur mengancam go-live date; dan dalam migrasi yang didorong deadline, go-live yang terlambat dapat berarti renegosiasi kontrak dan perpanjangan lisensi untuk legacy environment. Lebih buruk lagi, defects yang lolos masuk ke sistem baru sejak hari pertama — duplicate records yang memecah demand history, unfindable items yang mendorong free-text purchasing — secara diam-diam menjamin bahwa ERP baru yang mahal tersebut tidak memberikan performa yang lebih baik daripada sistem lama. High probability, high impact, long tail: itulah profil sebuah top-of-register risk.

Menulis Risk Statement: Entri yang Bisa Anda Adaptasi Hari Ini

Steering committee mengambil tindakan berdasarkan risk statements yang dirumuskan dengan baik, bukan berdasarkan kecemasan umum. Format terkuat menghubungkan condition, cause dan consequence dalam satu kalimat, yang membuat score maupun mitigation menjadi jelas. Tiga entri mencakup sebagian besar area material master untuk kebanyakan program ERP; sesuaikan angkanya dengan hasil assessment Anda sendiri.

Risk entry one — migration delay from duplicate and non-standard records. "Jika material master mengandung duplikasi yang signifikan dan deskripsi item yang tidak standar (diperkirakan 10–20 per cent dari ~[N] records, belum terverifikasi), yang disebabkan oleh pembuatan item yang tidak terkendali selama bertahun-tahun di berbagai site, maka data mapping dan load cycles akan gagal dalam validation dan memerlukan rework berulang, yang mengakibatkan schedule slippage selama satu hingga tiga bulan dan penggunaan sumber daya functional dan consultant yang lebih lama." Suggested initial scoring: probability high, impact high — yang dalam sebagian besar matriks menempatkannya di red zone dan mengharuskan active mitigation daripada acceptance.

Risk entry two — cutover defects from incomplete item data. "Jika item records tidak memiliki mandatory attributes, units of measure dan classifications yang dibutuhkan oleh target system, yang disebabkan oleh legacy fields yang tidak pernah di-govern, maka records akan ditolak atau dimuat dengan defects saat cutover, yang mengakibatkan procurement dan maintenance transactions gagal dalam minggu-minggu pertama operasional." Ini adalah risiko yang mengubah go-live week menjadi war room. Probability dapat diukur secara langsung dari sample assessment; impact melampaui IT dan masuk ke operations, yang merupakan alasan tepat mengapa entry ini harus berada di programme register dan bukan technical sub-plan.

Risk entry three — post-go-live degradation from absent data governance. "Jika tidak ada quality gate yang mengatur item creation di sistem baru, yang disebabkan oleh governance yang dikeluarkan dari scope migrasi, maka cleansed data akan mengalami degradation pada historical rate-nya, yang mengakibatkan business case benefits dari investasi ERP terkikis dalam 12–24 bulan." Program sering kali menutup yang satu ini sebagai "operational business-as-usual". Jangan lakukan itu. Migrasi yang menghasilkan data bersih ke dalam proses yang tidak di-govern hanya menjadwalkan relapse-nya sendiri.

Menilai Probability dan Impact Tanpa Guesswork

Sebuah register entry yang dinilai berdasarkan gut feel mengundang steering committee untuk mengabaikannya. Alternatif yang kredibel ternyata membutuhkan biaya yang sangat kecil: dukung score dengan evidence melalui sample-based data assessment sebelum register difinalisasi. Ukur actual duplication rate pada sample yang bermakna secara statistik; ukur description completeness terhadap mandatory fields pada target system; ukur classification coverage terhadap standard yang ingin Anda gunakan, baik UNSPSC maupun NATO codification. Setiap pengukuran mengubah argument menjadi angka, dan angka jauh lebih mampu bertahan dari scrutiny steering committee dibandingkan adjectives.

Assessment yang sama juga mempertajam sisi impact. Setelah Anda mengetahui defect rate, Anda dapat memodelkan load-failure volumes, memperkirakan rework effort dalam consultant-days, dan menerjemahkan schedule risk ke dalam dollars menggunakan daily run rate milik program itu sendiri. Seorang pemimpin IT yang menyampaikan risk entry berbunyi "probability 85 per cent, dibuktikan dengan 4,000-record sample assessment; impact $[X] per month of delay at current burn rate" tidak lagi meminta committee untuk mempercayai sebuah opini. Mereka sedang menyajikan sebuah keputusan yang menetapkan harganya sendiri.

Mitigasi Bertingkat dan Pertanyaan tentang Ownership

Setelah risiko diberi score, register menuntut mitigation plan dan owner — dan keduanya membutuhkan pemikiran yang lebih matang daripada yang biasanya diberikan.

Mitigation bekerja paling baik dalam beberapa tier yang disesuaikan dengan tingkat defect dan waktu yang tersedia. Tier pertama adalah assessment: mengukur masalah cukup awal sehingga setiap keputusan berikutnya mendapatkan informasi yang tepat. Tier kedua adalah remediation: melakukan cleansing, standardisasi dan klasifikasi terhadap records yang benar-benar akan dimigrasikan — yang biasanya berarti memprioritaskan active items dan high-value categories daripada mencoba menyelesaikan semuanya sekaligus. Ini adalah pekerjaan khusus; inilah tepatnya yang diberikan oleh professional cataloguing engagement, dengan cataloguers berpengalaman menyelesaikan duplicates melalui specification analysis, menulis ulang names dan descriptions mengikuti consistent convention, dan mengklasifikasikan items berdasarkan agreed standard — didukung oleh purpose-built tooling seperti SCS untuk pekerjaan cleansing, naming, describing dan classification, selalu di bawah judgement para cataloguers dan bukan menggantikan judgement tersebut. Tier ketiga adalah prevention: governed item-creation workflow di target system, sehingga risk entry pada akhirnya dapat ditutup dan bukan terus-menerus dibuka kembali.

Ownership adalah pertanyaan yang lebih subtil. Instingnya adalah memberikan risiko kepada IT, karena data berada di dalam systems. Insting tersebut salah, dan programme directors yang berpengalaman mengetahuinya: penyebabnya (uncontrolled item creation, unagreed standards) dan konsekuensinya (procurement failures, maintenance delays, working capital) semuanya berada di dalam business. Entry tersebut bekerja paling baik dengan business owner — biasanya supply chain atau asset management executive — yang bertanggung jawab atas risiko, sementara IT bertanggung jawab atas technical mitigation actions di bawahnya. Keputusan ownership tunggal tersebut mengubah percakapan dari "an IT data problem" menjadi "a business risk with a funded plan", yang merupakan inti dari menempatkannya di dalam register.

Kesimpulan

Gelombang migrasi ERP yang kini bergerak menuju puncaknya pada 2027 akan memisahkan organisasi menjadi dua kelompok: mereka yang memperlakukan material master data quality sebagai hal teknis yang dapat ditangani selama proyek, dan mereka yang memperlakukannya sebagai risiko nomor satu dalam program — didaftarkan, dinilai berdasarkan evidence, dimiliki oleh business dan dimitigasi secara bertingkat sebelum migrasi membutuhkan data tersebut. Sejarah tidak ambigu mengenai kelompok mana yang menyelesaikan proyek tepat waktu.

Kabar baik bagi para pemimpin IT adalah bahwa alat untuk mewujudkan hal ini sebenarnya sudah ada dan sudah mendapatkan respect dari committee: risk register itu sendiri. Tulis entry-nya, dukung score dengan evidence, tentukan owner-nya. Sebuah risiko yang secara formal terdaftar adalah risiko yang telah disepakati organisasi untuk dikelola — dan kesepakatan tersebut, lebih dari keputusan teknologi apa pun, adalah yang membedakan migrasi yang berhasil mendarat dari migrasi yang tertatih-tatih.

Letakkan Evidence di Balik Entry

Sebelum steering committee berikutnya, ada satu pertanyaan yang layak diselesaikan: apakah Anda dapat memberikan evidence untuk data quality risk entry — atau hanya menyatakannya?

Karena sebuah entry tanpa evidence mudah untuk diabaikan. Dan ketika entry tersebut diabaikan, konsekuensinya terus terakumulasi secara diam-diam: mapping cycles gagal, rework menghabiskan consultant-days, cutover dates menjadi tidak stabil, dan setelah go-live, duplicate records dan unfindable items terus memperlambat procurement serta membuat working capital tertahan di rak.

Di sebagian besar organisasi, hambatannya bukan ERP platform, dan bukan pula project team. Hambatannya adalah quality, governance dan searchability dari material master data yang mendasarinya — inconsistent descriptions, missing attributes dan classifications yang tidak akan dimaafkan oleh validation rule apa pun.

Itulah sebabnya di Panemu, kami membantu organisasi menetapkan kondisi sebenarnya dari material master data mereka melalui free consultation dan data assessment — mengukur duplication dan completeness pada sample nyata, menentukan besarnya migration risk dalam angka yang dapat ditindaklanjuti oleh steering committee, dan merekomendasikan jalur remediation yang praktis dan diprioritaskan untuk fondasi procurement, maintenance dan supply chain yang lebih kuat.

Karena risiko yang dapat Anda ukur adalah risiko yang dapat Anda hilangkan.

Penasaran berapa skor material master Anda jika dinilai minggu ini?

Kirimkan sample material master data Anda untuk free assessment, atau jadwalkan consultation dengan cataloguing team kami di https://panemu.com/cataloguing-service dan datang ke steering committee berikutnya dengan evidence di tangan.