Cleansing Ulang, atau Kendalikan Data Sejak Masuk ERP?

Pembersihan data master yang hanya dilakukan sekali biasanya hanya bertahan 12–24 bulan sebelum masalah kembali muncul. Pahami penyebabnya dan langkah pengendalian yang dapat diterapkan CIO serta penanggung jawab ERP untuk mencegah masalah sejak sumbernya.

The cleanse finished on schedule. Duplicates were merged, descriptions rewritten, obsolete codes flagged. Eighteen months later, the maintenance team is once again finding the same mechanical seal under three different codes, and someone in IT is drafting the scope for another clean-up.Proyek cleansing selesai tepat waktu. Data dobel sudah digabung, deskripsi ditulis ulang, kode yang tidak aktif sudah ditandai. Delapan belas bulan kemudian, tim maintenance kembali menemukan satu mechanical seal yang sama tercatat dengan tiga kode berbeda, dan tim IT mulai menyusun scope untuk proyek beres-beres berikutnya.

Nobody did anything wrong. Planners raised urgent requests, buyers created codes to keep purchase orders moving, and a new plant came online with its own habits. Each record made sense on the day it was created. Together, they rebuilt the problem the project had just solved.Tidak ada yang salah langkah. Planner mengajukan request mendesak, buyer membuat kode baru supaya PO segera jalan, dan plant baru mulai beroperasi dengan kebiasaannya sendiri. Setiap record masuk akal pada hari dibuat. Namun jika dikumpulkan, semuanya membangun kembali masalah yang baru saja dibereskan.

For CIOs and ERP owners planning the next master data initiative, this raises a sharper question than "how do we clean the data?" It is whether to budget for cleaning again, or to control how material master data enters the ERP in the first place. What does each path really cost, and what is the minimum you need in place for prevention to work?Bagi CIO dan pemilik ERP yang sedang merencanakan inisiatif Material Master Data berikutnya, pertanyaannya jadi lebih tajam daripada sekadar "bagaimana membersihkan data?". Apakah Anda akan kembali menganggarkan cleansing, atau mengendalikan cara data material masuk ke ERP sejak awal? Berapa biaya sebenarnya dari tiap jalur, dan kontrol minimum apa yang dibutuhkan agar pencegahan benar-benar berjalan?

The pattern: clean, degrade, clean againPolanya: bersihkan, menurun, bersihkan lagi

A cleansing project is a correction. It works on a snapshot: the records that exist on the day the extract is taken. It standardises descriptions, merges duplicates, fills missing attributes and retires codes nobody uses. Done well, it leaves the catalogue in far better shape than it found it.Proyek cleansing pada dasarnya adalah koreksi. Ia bekerja pada potret data: record yang ada di hari data diekstrak. Deskripsi distandarkan, data dobel digabung, atribut yang kosong dilengkapi, dan kode yang tidak terpakai dinonaktifkan. Jika dikerjakan dengan baik, katalog material jauh lebih rapi daripada sebelumnya.

What it does not touch is the process that produced the snapshot. The day after go-live, the same people, under the same pressures, start creating new records through the same channels. If those channels still accept free text, still issue a code without checking what already exists, and still allow a record to be saved with half its attributes blank, the catalogue starts drifting back.Yang tidak tersentuh adalah proses yang menghasilkan potret tersebut. Sehari setelah go-live, orang yang sama, dengan tekanan kerja yang sama, kembali membuat record baru lewat jalur yang sama. Selama jalur itu masih menerima teks bebas, masih menerbitkan kode tanpa mengecek data yang sudah ada, dan masih membolehkan record disimpan dengan separuh atribut kosong, katalog perlahan kembali ke kondisi lama.

How the drift happensBagaimana penurunan itu terjadi

  • Free-text descriptions. One user types "BEARING 6205", another "BRG 6205 2RS", a third "Ball bearing 6205-2RS for pump P-101". All three may describe the same item.Deskripsi teks bebas. Satu user mengetik "BEARING 6205", yang lain "BRG 6205 2RS", yang ketiga "Ball bearing 6205-2RS untuk pompa P-101". Ketiganya bisa jadi barang yang sama.
  • Urgency beats process. When a pump is down and a PO is needed today, creating a new code often feels quicker than searching for the right one.Situasi mendesak mengalahkan prosedur. Saat pompa berhenti dan PO harus keluar hari ini, membuat kode baru sering terasa lebih cepat daripada mencari kode yang benar.
  • Search that does not find. Inconsistent descriptions make search unreliable. The user concludes the item does not exist and requests a new code, so duplicates tend to create more duplicates.Pencarian yang tidak ketemu. Deskripsi yang tidak konsisten membuat pencarian tidak bisa diandalkan. User menyimpulkan barangnya belum ada lalu minta kode baru, sehingga data dobel cenderung melahirkan data dobel berikutnya.
  • Many hands. Several plants, contractors and new staff after turnover all create records, each with a slightly different idea of what "correct" looks like.Terlalu banyak tangan. Beberapa plant, kontraktor, dan staf baru setelah rotasi sama-sama membuat record, masing-masing dengan pemahaman sendiri tentang format yang "benar".
  • Change events. A new plant, an acquisition, an ERP migration or a batch of new equipment with its OEM spare parts list can add hundreds of records in a few weeks.Momen perubahan. Plant baru, akuisisi, migrasi ERP, atau kedatangan peralatan baru beserta daftar spare part dari OEM bisa menambah ratusan record dalam beberapa minggu.

None of this is unusual. These are the normal working conditions of an asset-intensive operation. That is why degradation tends to be gradual and quiet: no single record looks like a crisis, so nobody raises an alarm until search results become unreliable or a stock count shows the same part sitting in two bins under two codes.Semua ini wajar. Begitulah kondisi kerja sehari-hari di industri padat aset. Karena itu penurunan kualitas data cenderung berjalan pelan dan tidak terasa. Tidak ada satu record pun yang tampak seperti krisis, sehingga tidak ada yang membunyikan alarm sampai hasil pencarian tidak lagi bisa dipercaya, atau stock opname menemukan part yang sama tersimpan di dua bin dengan dua kode.

The cycle then completes itself. Confidence in the data drops, workarounds multiply, and the organisation commissions another cleanse. The project budget comes back, the consultants come back and, eventually, so does the problem.Lalu siklusnya berulang. Kepercayaan terhadap data turun, jalan pintas makin banyak, dan perusahaan kembali memesan proyek cleansing. Anggaran proyek muncul lagi, konsultan datang lagi, dan pada waktunya, masalahnya pun kembali.

The figure to know: 50–80% in 12–24 monthsAngka yang perlu diingat: 50–80% dalam 12–24 bulan

Here is the number worth keeping in mind. Without daily governance, material master data quality can degrade by 50–80% within 12–24 months after a cleanse, as free-text entries and duplicates come back through routine transactions.Ini angka yang perlu Anda pegang saat menyusun rencana. Tanpa tata kelola harian, kualitas Material Master Data bisa turun 50–80% dalam 12–24 bulan setelah cleansing, karena entri teks bebas dan data dobel masuk kembali lewat transaksi rutin.

The range is wide for a reason. How fast quality falls depends on how many new codes the organisation creates each month, how many people can create them, how much change the business is going through, and how strict the entry rules are. A site adding a few dozen codes a month through one experienced team will usually drift more slowly than a group with several plants, high staff turnover and an equipment upgrade programme under way.Rentangnya lebar karena memang banyak faktor yang memengaruhi. Kecepatan penurunan bergantung pada berapa banyak kode baru yang dibuat tiap bulan, berapa orang yang boleh membuatnya, seberapa besar perubahan yang sedang terjadi di bisnis, dan seberapa ketat aturan entri data. Satu site yang menambah beberapa puluh kode per bulan lewat satu tim berpengalaman biasanya menurun lebih lambat dibanding grup dengan beberapa plant, rotasi staf tinggi, dan program penggantian peralatan yang sedang berjalan.

What the range does make clear is the time frame. Twelve to twenty-four months is roughly one or two budget cycles. A cleanse completed this year can be largely undone before the next ERP roadmap review. If a programme is justified on the basis of cleaner data, that benefit has a shelf life unless something changes at the point of entry.Yang jelas dari rentang ini adalah jangka waktunya. Dua belas sampai dua puluh empat bulan kira-kira setara satu atau dua siklus anggaran. Hasil cleansing tahun ini bisa sebagian besar hilang sebelum review roadmap ERP berikutnya. Jika sebuah program dijustifikasi dengan alasan data yang lebih bersih, manfaat itu punya masa kedaluwarsa, kecuali ada yang berubah di titik masuk data.

Data quality over 24 months after a one-off cleanseKualitas data selama 24 bulan setelah cleansing satu kali

Quality index (100 = immediately after the cleanse)Indeks kualitas (100 = sesaat setelah cleansing)

100 50 0
0 6 12 18 24

Months after the cleanseBulan setelah cleansing

Cleanse completedCleansing selesai No daily governance: 50–80% degradation rangeTanpa tata kelola harian: rentang penurunan 50–80% With daily governance (illustrative)Dengan tata kelola harian (ilustratif) 12–24 month windowRentang bulan ke-12 sampai ke-24

Conceptual illustration, not based on measured data. The orange band reflects the 50–80% degradation range cited above; the curve shapes are indicative. The "with daily governance" line is illustrative only, as no figure is available for it.Ilustrasi konseptual, bukan hasil pengukuran. Area oranye menggambarkan rentang penurunan 50–80% yang disebut di atas; bentuk kurvanya hanya indikatif. Garis "dengan tata kelola harian" murni ilustrasi karena tidak ada angka yang tersedia untuknya.

What degradation looks like from the ERP owner's deskSeperti apa penurunan itu dari sisi pemilik ERP

The decline rarely shows up as a single metric on a dashboard. It shows up as symptoms that are easy to treat one at a time:Penurunan ini jarang muncul sebagai satu angka di dashboard. Biasanya ia muncul sebagai gejala yang mudah ditangani satu per satu:

  • More "item not found" searches, followed by new code requests.Makin sering pencarian "barang tidak ditemukan", lalu disusul request kode baru.
  • A rising share of records with blank, "TBA" or "see drawing" attributes.Porsi record dengan atribut kosong, "TBA", atau "lihat gambar" terus bertambah.
  • The same manufacturer part number linked to several material codes.Satu part number manufacturer terhubung ke beberapa kode material.
  • Planners keeping private spreadsheets of "the code that actually works".Planner menyimpan spreadsheet pribadi berisi "kode yang benar-benar dipakai".
  • Support tickets asking IT to merge, block or correct records.Tiket support yang meminta IT menggabung, memblokir, atau mengoreksi record.

Each of these carries a cost that sits outside the data team: slower purchase requisitions, stock split across codes, emergency buys for parts already on the shelf, and inventory valuations that are harder to defend at audit. By the time the symptoms are visible enough to fund a project, much of that cost has already been paid.Setiap gejala membawa biaya yang tidak tercatat di tim data: purchase requisition yang lebih lambat, stok yang terpecah ke beberapa kode, pembelian darurat untuk part yang sebenarnya sudah ada di rak, dan nilai inventory yang lebih sulit dipertanggungjawabkan saat audit. Ketika gejalanya sudah cukup terlihat untuk mendapat anggaran proyek, sebagian besar biaya itu sudah terlanjur keluar.

Is your last cleanse already drifting?Apakah hasil cleansing terakhir Anda mulai bergeser?

Let's look at how new material codes are being created in your ERP today.Mari lihat bersama bagaimana kode material baru dibuat di ERP Anda saat ini.

Talk to Our TeamDiskusi dengan Tim Kami

The strategic choice: recurring clean-ups, or a control at the sourcePilihan strategisnya: cleansing berulang, atau kontrol di sumber

Seen this way, the decision is not really cleansing versus no cleansing. Most organisations with years of legacy data will need at least one serious clean-up. The real choice is what happens after it.Jika dilihat dari sudut ini, keputusannya bukan soal perlu cleansing atau tidak. Sebagian besar perusahaan dengan legacy data bertahun-tahun tetap butuh setidaknya satu kali cleansing yang serius. Pilihan sebenarnya ada pada apa yang terjadi sesudahnya.

Option one is to accept the cycle and plan for it: a cleanse every two or three years, budgeted as a recurring project. This is a legitimate strategy. It is predictable, it fits project-based funding, and it does not require changing daily behaviour across departments.Opsi pertama adalah menerima siklusnya dan merencanakannya: cleansing setiap dua atau tiga tahun, dianggarkan sebagai proyek berulang. Ini strategi yang sah. Mudah diprediksi, cocok dengan pola pendanaan berbasis proyek, dan tidak menuntut perubahan kebiasaan kerja harian di banyak departemen.

Option two is to put a control at the source, so every new record passes through the same rules before it receives a code. The clean-up still happens once, but the effort afterwards shifts from periodic correction to daily prevention.Opsi kedua adalah memasang kontrol di sumber, sehingga setiap record baru melewati aturan yang sama sebelum mendapat kode. Cleansing tetap dilakukan sekali, tetapi upaya sesudahnya bergeser dari koreksi berkala menjadi pencegahan harian.

AspectAspekRecurring clean-upsCleansing berulangControl at the sourceKontrol di sumber
What it fixesYang diperbaikiRecords that already existRecord yang sudah adaRecords before they are createdRecord sebelum dibuat
How cost landsPola biayaLarge, visible project every few yearsProyek besar dan terlihat setiap beberapa tahunSmaller, steady operating costBiaya operasional yang lebih kecil dan stabil
Between projectsDi antara proyekQuality tends to decline; workarounds growKualitas cenderung turun; jalan pintas bertambahQuality is monitored and held at the gateKualitas dipantau dan dijaga di pintu masuk
OwnershipKepemilikanProject team, until the project closesTim proyek, sampai proyek ditutupPermanent owner with clear decision rulesPemilik tetap dengan aturan keputusan yang jelas
Change for usersPerubahan bagi userLittle day to dayHampir tidak ada di keseharianA defined path and required fields for new codesJalur baku dan field wajib untuk kode baru
Main riskRisiko utamaPaying for the same work repeatedlyMembayar pekerjaan yang sama berulang kaliA gate that is too slow and gets bypassedPintu masuk yang terlalu lambat sehingga dilewati

Neither option is free. Recurring clean-ups concentrate cost in large, visible projects. Prevention spreads a smaller cost across daily operations and asks departments to accept a gate on code creation. For a CIO, the useful comparison is the total cost over, say, five years, including the operational losses that build up between cleanses, rather than the price of a single project.Kedua opsi sama-sama butuh biaya. Cleansing berulang memusatkan biaya pada proyek besar yang terlihat jelas. Pencegahan menyebar biaya yang lebih kecil ke operasional harian, dan meminta departemen menerima adanya pintu kontrol saat membuat kode. Bagi CIO, perbandingan yang berguna adalah total biaya dalam, misalnya, lima tahun, termasuk kerugian operasional yang menumpuk di antara dua proyek cleansing, bukan harga satu proyek saja.

There is also a governance argument. A cleanse is owned by a project; when the project closes, ownership closes with it. A control at the source needs a permanent owner, clear rules and someone accountable for decisions on borderline requests. That is harder to set up, but it is also what turns master data from a recurring problem into a managed asset.Ada juga pertimbangan Data Governance. Cleansing dimiliki oleh proyek; begitu proyek ditutup, kepemilikannya ikut selesai. Kontrol di sumber membutuhkan pemilik tetap, aturan yang jelas, dan orang yang bertanggung jawab memutuskan request yang abu-abu. Memang lebih sulit disiapkan, tetapi justru di situlah master data berubah dari masalah yang berulang menjadi aset yang dikelola.

A cleanse fixes today's records. A control at the source decides what tomorrow's records look like.Cleansing memperbaiki record hari ini. Kontrol di sumber menentukan wujud record esok hari.

Weighing another clean-up against prevention?Sedang menimbang cleansing ulang atau pencegahan?

We can help you lay out both paths for your ERP before you commit budget.Kami bisa membantu memetakan kedua jalur untuk ERP Anda sebelum anggaran diputuskan.

Talk to Our TeamDiskusi dengan Tim Kami

The technical minimum for preventionKontrol teknis minimum untuk pencegahan

Prevention does not need a large technology programme to get started. Three controls do most of the work, and each one addresses a specific way in which quality drifts.Pencegahan tidak harus dimulai dengan program teknologi besar. Tiga kontrol sudah menangani sebagian besar pekerjaan, dan masing-masing menjawab satu penyebab spesifik turunnya kualitas data.

1. Duplicate screening before a code is issued1. Duplicate screening sebelum kode diterbitkan

The cheapest duplicate to fix is the one stopped before it receives a code. Before a new material is created, the request should be checked against existing records: by manufacturer part number, by manufacturer, by normalised description and by key attributes. Matching on description alone tends to miss duplicates, because inconsistent descriptions are the very problem being solved.Data dobel yang paling murah untuk dibereskan adalah yang dihentikan sebelum mendapat kode. Sebelum material baru dibuat, request perlu dicocokkan dengan record yang sudah ada: berdasarkan part number, manufacturer, deskripsi yang sudah dinormalisasi, dan atribut kunci. Pencocokan lewat deskripsi saja cenderung meloloskan data dobel, karena deskripsi yang tidak konsisten itulah masalah utamanya.

Screening works best as a step in the workflow rather than an optional search. If the requester sees likely matches before submitting, many duplicate requests stop right there. If the request still goes ahead, a reviewer can see the candidates side by side and make the call.Screening paling efektif jika menjadi langkah wajib di workflow, bukan pencarian opsional. Jika peminta sudah melihat kemungkinan data yang cocok sebelum mengirim request, banyak request dobel berhenti di situ. Jika request tetap diajukan, reviewer bisa membandingkan kandidatnya berdampingan lalu memutuskan.

2. Noun-modifier templates2. Template noun-modifier

A noun-modifier convention gives every item a controlled class name. The noun states what the item is; the modifier narrows it down: SEAL, MECHANICAL. VALVE, GATE. BEARING, BALL. Each class then has its own template listing the attributes that define an item of that kind.Naming convention noun-modifier memberi setiap barang nama kelas yang terkendali. Noun menyatakan barang apa itu, modifier mempersempitnya: SEAL, MECHANICAL. VALVE, GATE. BEARING, BALL. Setiap kelas lalu punya template sendiri yang memuat atribut penentu untuk jenis barang tersebut.

Templates do two jobs. They make descriptions consistent, so search works and duplicates become visible. And they tell the requester what information is needed, so the request arrives complete instead of as a single line of free text.Template punya dua fungsi. Pertama, deskripsi jadi konsisten sehingga pencarian berjalan dan data dobel lebih mudah terlihat. Kedua, template memberi tahu peminta informasi apa saja yang dibutuhkan, sehingga request datang lengkap, bukan sekadar satu baris teks bebas.

3. Mandatory attributes3. Atribut wajib

A template only helps if its key fields are actually filled. For each class, a small set of attributes should be required before the record can be saved. For a mechanical seal, that typically includes seal type, arrangement, shaft diameter, face materials, elastomer and manufacturer part number. Other attributes can stay optional.Template hanya berguna jika field kuncinya benar-benar diisi. Untuk setiap kelas, perlu ada sejumlah kecil atribut yang wajib diisi sebelum record bisa disimpan. Untuk mechanical seal, biasanya mencakup tipe seal, arrangement, diameter shaft, material seal face, elastomer, dan part number manufacturer. Atribut lain bisa tetap opsional.

The judgement lies in keeping the mandatory set short. Require too many fields and users will type placeholders to get past the form, recreating the problem in a different shape. Require too few and two different items can end up with identical descriptions.Kuncinya adalah menjaga daftar atribut wajib tetap pendek. Terlalu banyak field wajib, user akan mengisi asal-asalan supaya formnya lolos, dan masalah lama muncul dalam bentuk baru. Terlalu sedikit, dua barang yang berbeda bisa berakhir dengan deskripsi yang sama persis.

One item, described the same way every timeSatu barang, dideskripsikan dengan cara yang sama setiap kali

How it often arrives as free textSeperti yang sering masuk sebagai teks bebas

  • mech seal 50mm pump P-101
  • SEAL MECH CART 50
  • Mechanical seal cartridge type, shaft 50

With a noun-modifier templateDengan template noun-modifier

SEAL, MECHANICAL: CARTRIDGE, SINGLE, 50MM, SIC/SIC, FKM

  • Noun / modifierNoun / modifierSEAL / MECHANICAL
  • Seal typeTipe sealCartridge
  • ArrangementArrangementSingle
  • Shaft diameterDiameter shaft50 mm
  • Face materialsMaterial seal faceSiC / SiC
  • ElastomerElastomerFKM
  • Manufacturer part numberPart number manufacturerRequired fieldField wajib
  • Equipment referenceReferensi equipmentP-101
Mandatory attributeAtribut wajib Optional attributeAtribut opsional

Example for illustration. Actual classes, attribute sets and description formats follow each organisation's own cataloguing standard.Contoh untuk ilustrasi. Kelas, set atribut, dan format deskripsi yang sebenarnya mengikuti standar katalog masing-masing perusahaan.

The difference is not cosmetic. With the template, the system can compare this seal against existing records attribute by attribute. With free text, it can only guess, and a reviewer has to open each candidate to check.Perbedaannya bukan sekadar tampilan. Dengan template, sistem bisa membandingkan seal ini dengan record yang sudah ada, atribut demi atribut. Dengan teks bebas, sistem hanya bisa menebak, dan reviewer harus membuka setiap kandidat satu per satu untuk mengecek.

How the roles split: ANSI and SCS®Pembagian peran: ANSI dan SCS®

A note on naming. In this article, ANSI refers to Panemu's master data governance application. It is not the American National Standards Institute.Catatan soal nama. Dalam artikel ini, ANSI merujuk pada aplikasi master data governance milik Panemu, bukan American National Standards Institute.

Prevention depends on two capabilities that are easy to blur together: deciding what may enter the ERP, and preparing the data so it is fit to enter. In Panemu's approach, these sit with two separate components.Pencegahan bergantung pada dua kemampuan yang sering tercampur: memutuskan data apa yang boleh masuk ke ERP, dan menyiapkan data supaya layak masuk. Dalam pendekatan Panemu, keduanya dipegang oleh dua komponen yang berbeda.

ANSI: the gateANSI: pintu masuk

Decides what may enter the ERP, so new codes follow one controlled path.Memutuskan data apa yang boleh masuk ke ERP, sehingga kode baru melewati satu jalur terkendali.

  • One entry path for new material codesSatu jalur masuk untuk kode material baru
  • Decision point: approve, reject or reuseTitik keputusan: setujui, tolak, atau pakai yang ada
  • Clear accountability for each entry decisionAkuntabilitas jelas untuk setiap keputusan

SCS®: the preparationSCS®: penyiapan data

Prepares and standardises the data, so each request is complete and comparable.Menyiapkan dan menstandarkan data, sehingga setiap request lengkap dan bisa dibandingkan.

  • Noun-modifier naming applied consistentlyPenamaan noun-modifier yang konsisten
  • Class attributes completed to the templateAtribut kelas dilengkapi sesuai template
  • Descriptions ready for duplicate comparisonDeskripsi siap untuk pengecekan data dobel

Where each role sits in the path of a new codePosisi tiap peran di jalur kode baru

  1. Request raisedRequest diajukan
  2. SCS® prepares & standardisesSCS® menyiapkan & menstandarkan
  3. ANSI screens & decidesANSI menyaring & memutuskan
  4. Code issued in ERPKode terbit di ERP

Simplified view. Actual workflow steps and approval levels are set per organisation.Gambaran sederhana. Langkah workflow dan level approval sebenarnya disesuaikan dengan tiap perusahaan.

Separating the roles matters because each fails differently on its own. Standardisation without a gate tends to produce well-formatted duplicates. A gate without standardisation produces a slow queue of requests nobody can compare with confidence. Working together, the two are designed to help keep the catalogue close to the condition the original cleanse left it in.Pemisahan peran ini penting karena masing-masing punya kelemahan jika berjalan sendiri. Standardisasi tanpa pintu masuk cenderung menghasilkan data dobel yang formatnya rapi. Pintu masuk tanpa standardisasi menghasilkan antrean request yang lambat dan sulit dibandingkan dengan yakin. Jika berjalan bersama, keduanya dirancang untuk membantu menjaga katalog tetap mendekati kondisi setelah cleansing awal.

For an ERP owner, the split also clarifies responsibility. The question "who let this record in?" has a clear answer, and so does "who made it look like this?". That clarity is usually what is missing when quality drifts after a cleanse.Bagi pemilik ERP, pembagian ini juga memperjelas tanggung jawab. Pertanyaan "siapa yang meloloskan record ini?" punya jawaban yang jelas, begitu juga "siapa yang menyiapkan formatnya?". Kejelasan seperti inilah yang biasanya hilang ketika kualitas data mulai turun setelah cleansing.

Want a control at your ERP's entry point?Ingin memasang kontrol di pintu masuk ERP Anda?

See how ANSI and SCS® could fit the way your teams create material codes.Lihat bagaimana ANSI dan SCS® bisa menyesuaikan cara tim Anda membuat kode material.

Talk to Our TeamDiskusi dengan Tim Kami

Five questions before you approve the next data initiativeLima pertanyaan sebelum menyetujui inisiatif data berikutnya

Whichever path you lean towards, these questions help test whether the plan addresses the source of the problem or only its current symptoms. Treat them as a starting point for discussion with your data, procurement and maintenance leads.Apa pun jalur yang Anda pilih, pertanyaan berikut membantu menguji apakah rencana tersebut menyentuh sumber masalah atau hanya gejala yang terlihat sekarang. Gunakan sebagai bahan diskusi awal dengan pimpinan tim data, procurement, dan maintenance.

  1. How many new material codes are created each month, and by how many people? Volume and the number of creators largely set the pace of degradation.Berapa kode material baru yang dibuat tiap bulan, dan oleh berapa orang? Volume dan jumlah pembuat kode sangat menentukan kecepatan penurunan kualitas.
  2. What does a requester see before a code is issued? If the answer is "an empty form", duplicate screening is not yet part of the process.Apa yang dilihat peminta sebelum kode diterbitkan? Jika jawabannya "form kosong", berarti duplicate screening belum menjadi bagian dari proses.
  3. Which classes have templates and mandatory attributes? Classes that still accept free text are where drift tends to start.Kelas mana saja yang sudah punya template dan atribut wajib? Kelas yang masih menerima teks bebas biasanya menjadi titik awal penurunan.
  4. Who owns the entry decision once the project team leaves? Without a named owner, governance tends to fade with the project.Siapa pemilik keputusan entri setelah tim proyek selesai? Tanpa pemilik yang jelas, tata kelola cenderung ikut hilang bersama proyeknya.
  5. What should the data look like 24 months after go-live, and how will you know? Agree on a few measures now, so drift is visible early.Seperti apa kondisi data 24 bulan setelah go-live, dan bagaimana Anda mengetahuinya? Sepakati beberapa ukuran sejak sekarang agar penurunan terlihat lebih awal.

Key TakeawaysPoin Penting

  • A cleanse corrects today's records. It does not change how tomorrow's records are created.Cleansing memperbaiki record hari ini, tetapi tidak mengubah cara record esok hari dibuat.
  • Without daily governance, material master data quality can degrade by 50–80% within 12–24 months, roughly one or two budget cycles.Tanpa tata kelola harian, kualitas Material Master Data bisa turun 50–80% dalam 12–24 bulan, kira-kira satu atau dua siklus anggaran.
  • The strategic choice is between planning for recurring clean-ups and putting a control at the source. Compare them on multi-year total cost, not on a single project.Pilihan strategisnya adalah merencanakan cleansing berulang atau memasang kontrol di sumber. Bandingkan dari total biaya beberapa tahun, bukan dari satu proyek.
  • The technical minimum: duplicate screening before a code is issued, noun-modifier templates and a short list of mandatory attributes.Kontrol teknis minimum: duplicate screening sebelum kode terbit, template noun-modifier, dan daftar atribut wajib yang ringkas.
  • In Panemu's approach, ANSI decides what may enter the ERP, while SCS® prepares and standardises it.Dalam pendekatan Panemu, ANSI memutuskan data apa yang boleh masuk ke ERP, sementara SCS® menyiapkan dan menstandarkannya.