Daily Cataloguing: Stopping ERP Material Data Decay

Clean material data can decay once new requests bypass screening. See how Daily Cataloguing governs CRUD and filters duplicates before ERP entry.

The cleansing project closed on time. Descriptions followed one pattern, duplicates had been merged, and every active item carried a class code. A year later, a routine review of newly created material codes tells a different story: free-text descriptions are back, several new codes duplicate items that already existed, and one record created during a shutdown simply reads PART FOR COMPRESSOR.Proyek cleansing selesai tepat waktu. Deskripsi sudah mengikuti satu pola, data dobel sudah digabung, dan setiap item aktif sudah punya kode kelas. Setahun kemudian, review rutin atas kode material yang baru dibuat menunjukkan cerita lain: deskripsi teks bebas muncul lagi, beberapa kode baru ternyata dobel dengan item yang sudah ada, dan satu record yang dibuat saat shutdown hanya bertuliskan PART FOR COMPRESSOR.

Nothing broke. The catalogue was simply left open at the front door. Every day, requests arrived from maintenance, warehouse and project teams, and many went straight into the ERP without anyone checking whether the item already existed or whether its description met the standard.Tidak ada yang rusak secara tiba-tiba. Katalognya hanya dibiarkan terbuka di pintu depan. Setiap hari, request datang dari tim maintenance, gudang, dan proyek, dan banyak yang langsung masuk ke ERP tanpa ada yang mengecek apakah itemnya sudah ada atau apakah deskripsinya sesuai standar.

That slow slide is data degradation, and it is exactly what Daily Cataloguing is designed to help prevent. Why does clean material data decay once a project ends? How should Create, Change and Delete requests be governed? And what does a screening workflow look like before a code reaches SAP, Maximo, Oracle or Odoo?Kemerosotan perlahan itulah yang disebut degradasi data, dan inilah yang ingin dicegah oleh Daily Cataloguing. Kenapa data material yang sudah bersih bisa merosot lagi setelah proyek selesai? Bagaimana request Create, Change, dan Delete seharusnya dikelola? Lalu, seperti apa workflow penyaringan sebelum sebuah kode masuk ke SAP, Maximo, Oracle, atau Odoo?

Why clean data decays: the logic of an open catalogueKenapa data bersih bisa rusak lagi: logika katalog yang dibiarkan terbuka

A cleansing project fixes a snapshot. The catalogue itself keeps moving: new equipment arrives, manufacturers supersede part numbers, specifications are corrected, and items become obsolete. At any point in time, the quality of your material master reflects two things: the baseline you started with, and the quality of every transaction made since.Proyek cleansing memperbaiki kondisi data pada satu titik waktu. Sementara itu, katalognya terus bergerak: equipment baru datang, manufacturer mengganti part number, spesifikasi dikoreksi, dan item menjadi usang. Kapan pun Anda melihatnya, kualitas Material Master mencerminkan dua hal: baseline awal, dan kualitas setiap transaksi yang terjadi sesudahnya.

Consider a multi-site operation that creates around 150 new material codes a month. If one in ten of those is a duplicate or poorly described, that adds roughly 180 problematic records a year, each capable of splitting stock or confusing a buyer. The figures are illustrative, but the logic holds at any scale: small leaks compound, and they compound faster when request volume is high.Misalnya, sebuah perusahaan multi-site membuat sekitar 150 kode material baru setiap bulan. Jika satu dari sepuluh kode itu dobel atau deskripsinya buruk, berarti ada sekitar 180 record bermasalah setiap tahun, dan masing-masing bisa memecah stok atau membingungkan buyer. Angka ini hanya ilustrasi, tetapi logikanya berlaku di skala apa pun: kebocoran kecil akan menumpuk, dan makin cepat menumpuk ketika volume request tinggi.

Share of records meeting the catalogue standard after a cleansing projectPorsi record yang memenuhi standar katalog setelah proyek cleansing

Go-liveGo-live Month 6Bulan 6 Month 12Bulan 12 Month 18Bulan 18 Month 24Bulan 24
Requests screened by Daily CataloguingRequest disaring lewat Daily Cataloguing Requests go straight into the ERPRequest langsung masuk ERP

Conceptual illustration, not based on measured data. The actual rate of decay depends on request volume, number of users with create rights and the controls in place.Ilustrasi konseptual, bukan hasil pengukuran. Kecepatan degradasi sebenarnya bergantung pada volume request, jumlah user yang punya hak membuat kode, dan kontrol yang berjalan.

Four ways decay gets back inEmpat jalan masuk degradasi

Urgent requests that bypass the process. A breakdown needs a part today, so someone with create rights opens a code directly. The item may already exist under another name, but nobody has time to look.Request mendesak yang melewati proses. Ada breakdown yang butuh part hari itu juga, sehingga orang yang punya hak akses langsung membuat kode. Bisa jadi itemnya sudah ada dengan nama lain, tetapi tidak ada waktu untuk mencarinya.

Many hands, no single pattern. When dozens of users across sites can create items, each brings a personal style of describing parts. Even with a naming convention on paper, drift begins as soon as it is not enforced at the point of entry.Banyak tangan, tanpa satu pola. Ketika puluhan user di berbagai site bisa membuat item, masing-masing membawa gayanya sendiri dalam mendeskripsikan part. Meskipun naming convention sudah tertulis, pergeseran dimulai begitu aturan itu tidak ditegakkan di titik input.

Uncontrolled changes. Editing the description of an existing code to "fix" it can quietly change what the code means, while stock, open POs and bills of materials still point to the old item.Perubahan tanpa kontrol. Mengedit deskripsi kode yang sudah ada untuk "membetulkannya" bisa diam-diam mengubah arti kode itu, padahal stok, PO terbuka, dan bill of materials masih merujuk ke barang yang lama.

Obsolete items left active. Obsolete and superseded codes stay active and searchable, so users keep picking them, ordering them and creating new variations around them.Item usang yang dibiarkan aktif. Kode usang dan kode yang sudah digantikan tetap aktif dan muncul di pencarian, sehingga user terus memilihnya, memesannya, bahkan membuat variasi baru di sekitarnya.

AssumptionAnggapanOnce the data is clean, it stays clean.Kalau data sudah bersih, ia akan tetap bersih.
In practiceKenyataannyaQuality reflects every transaction made since the baseline.Kualitas data mencerminkan setiap transaksi sejak baseline dibuat.
AssumptionAnggapanMandatory fields in the ERP are enough.Field wajib di ERP sudah cukup.
In practiceKenyataannyaMandatory fields confirm that something was entered, not that it is correct or unique.Field wajib hanya memastikan ada isinya, bukan bahwa isinya benar atau unik.
AssumptionAnggapanGovernance slows maintenance down.Tata kelola memperlambat maintenance.
In practiceKenyataannyaA clear SLA and an emergency lane can keep speed while protecting the catalogue.SLA yang jelas dan jalur darurat bisa menjaga kecepatan sekaligus melindungi katalog.

Is your clean baseline already slipping?Apakah baseline bersih Anda mulai merosot?

Let's review a sample of recently created codes and see where new requests are leaking through.Mari tinjau sampel kode yang baru dibuat dan lihat dari mana request baru lolos tanpa saringan.

Request a Data ReviewMinta Review Data

CRUD governance: every change to the catalogue is a transactionTata kelola CRUD: setiap perubahan katalog adalah transaksi

CRUD is borrowed from software: Create, Read, Update and Delete. Applied to Material Master Data, it offers a useful way to see that the catalogue is not only changed by new items. Corrections and retirements alter it just as much, and each type of request carries different risks.CRUD adalah istilah dari dunia software: Create, Read, Update, dan Delete. Jika diterapkan pada Material Master Data, istilah ini membantu melihat bahwa katalog tidak hanya berubah karena item baru. Koreksi dan penonaktifan item juga mengubahnya, dan setiap jenis request membawa risiko yang berbeda.

The letter most often forgotten is R. Before anything is created, someone should search properly. A workflow that makes searching by attributes easy tends to prevent more duplicates than any clean-up that follows.Huruf yang paling sering terlupakan adalah R. Sebelum membuat apa pun, seseorang perlu mencari dengan benar. Workflow yang memudahkan pencarian berdasarkan atribut biasanya mencegah lebih banyak data dobel dibanding pembersihan apa pun sesudahnya.

Four request types, four different gatesEmpat jenis request, empat gerbang berbeda

CCreateCreate
TriggerPemicu
New equipment or spare, no match foundEquipment atau spare part baru, tidak ada yang cocok
GateGerbang
Duplicate screening and complete templatePenyaringan data dobel dan template lengkap
OutputHasil
A new Golden RecordGolden Record baru
RReadRead
TriggerPemicu
Any need for a partSetiap kebutuhan part
GateGerbang
Search by class and attributes, not just textCari berdasarkan kelas dan atribut, bukan sekadar teks
OutputHasil
Existing code reusedKode yang sudah ada dipakai ulang
UChangeChange
TriggerPemicu
Spec correction, new part number, supersessionKoreksi spesifikasi, part number baru, penggantian part
GateGerbang
Impact check on stock, open POs and BOMsCek dampak ke stok, PO terbuka, dan BOM
OutputHasil
Controlled update with audit trailPembaruan terkontrol dengan jejak audit
DDeleteDelete
TriggerPemicu
Obsolete, superseded or duplicate itemItem usang, sudah digantikan, atau dobel
GateGerbang
No remaining stock, open documents or BOM linksTidak ada sisa stok, dokumen terbuka, atau keterkaitan BOM
OutputHasil
Blocked record mapped to its successorRecord diblokir dan dipetakan ke penggantinya

Create: proving the item is genuinely newCreate: membuktikan item memang benar-benar baru

A create request should carry enough information to be judged: the noun and modifier, the mandatory attributes for that class, the manufacturer and part number where available, and the reason for the request, such as new equipment or a first-time spare. The burden of proof sits with the request: it has to show that no suitable code already exists.Request create perlu membawa informasi yang cukup untuk dinilai: noun dan modifier, atribut wajib untuk kelas tersebut, manufacturer dan part number jika tersedia, serta alasan request, misalnya equipment baru atau spare part yang baru pertama kali dibutuhkan. Beban pembuktiannya ada di request: harus bisa menunjukkan bahwa belum ada kode yang sesuai.

Change: correct the record without changing its meaningChange: koreksi record tanpa mengubah maknanya

Change requests are where good intentions can do the most damage. A useful rule of thumb comes from engineering practice: if the change affects form, fit or function, it usually warrants a new code linked to the old one as a successor. If it only corrects or completes information about the same physical item, it can be a controlled update. Either way, the workflow should show the requester what depends on the record before the change is approved.Request change adalah area di mana niat baik justru bisa menimbulkan kerusakan paling besar. Ada patokan praktis dari dunia engineering: jika perubahan memengaruhi form, fit, atau function, biasanya perlu kode baru yang ditautkan ke kode lama sebagai penggantinya. Jika hanya mengoreksi atau melengkapi informasi untuk barang fisik yang sama, cukup dilakukan sebagai pembaruan terkontrol. Apa pun jenisnya, workflow perlu menunjukkan kepada requester apa saja yang bergantung pada record tersebut sebelum perubahan disetujui.

Delete: retire, block and redirectDelete: nonaktifkan, blokir, dan arahkan

In most ERP and EAM systems, "delete" rarely means physically removing a record, because purchase history, movements and maintenance records still refer to it. It usually means changing the item's status so it can no longer be used in new transactions, and pointing users to a successor where one exists. The mechanism differs between platforms.Di sebagian besar sistem ERP dan EAM, "delete" jarang berarti menghapus record secara fisik, karena histori pembelian, pergerakan stok, dan catatan maintenance masih merujuk ke record itu. Biasanya yang dilakukan adalah mengubah status item agar tidak bisa dipakai di transaksi baru, lalu mengarahkan user ke item pengganti jika ada. Mekanismenya berbeda di tiap platform.

PlatformPlatform Typical way to retire an itemCara umum menonaktifkan item What to plan forYang perlu direncanakan
SAPSAP Deletion flag at the relevant organisational level, archived laterDeletion flag di level organisasi yang relevan, lalu diarsipkan belakangan Clear remaining stock and open documents firstBereskan dulu sisa stok dan dokumen terbuka
IBM MaximoIBM Maximo Item status change, for example to pending obsolete, then obsoletePerubahan status item, misalnya ke pending obsolete, lalu obsolete Let remaining stock be consumed before final statusHabiskan sisa stok sebelum status akhir diterapkan
OracleOracle Item status such as Inactive or Obsolete, depending on setupStatus item seperti Inactive atau Obsolete, tergantung konfigurasi Agree which transactions each status allowsSepakati transaksi apa saja yang diizinkan untuk tiap status
OdooOdoo Archive the product so it no longer appears in selectionArsipkan produk agar tidak muncul lagi di pilihan Check reordering rules and open orders beforehandCek reordering rule dan order terbuka lebih dulu

Behaviour varies by version and configuration. Confirm the exact process with your system administrator.Perilaku sistem berbeda tergantung versi dan konfigurasi. Pastikan proses persisnya dengan administrator sistem Anda.

Need clearer rules for Create, Change and Delete?Butuh aturan Create, Change, dan Delete yang lebih jelas?

Discuss with our team how CRUD rules could fit your ERP or EAM and your approval structure.Diskusikan dengan tim kami bagaimana aturan CRUD bisa diterapkan di ERP atau EAM dan struktur approval Anda.

Discuss CRUD RulesDiskusikan Aturan CRUD

Inside the workflow: screening at source, verification and the approval gateDi dalam workflow: penyaringan di sumber, verifikasi, dan approval gate

Daily Cataloguing works best as a single, visible route from request to ERP. Each role has one job, and each step filters out a different kind of problem before it becomes a permanent record.Daily Cataloguing paling efektif jika berupa satu jalur yang jelas dari request sampai ERP. Setiap peran punya satu tugas, dan setiap langkah menyaring jenis masalah yang berbeda sebelum menjadi record permanen.

From request to ERP: who does whatDari request sampai ERP: siapa mengerjakan apa

RequesterRequester
1Search, then submit on templateCari dulu, lalu ajukan lewat template
ScreeningPenyaringan
2Automated duplicate and completeness checkCek otomatis data dobel dan kelengkapan
CataloguerCataloguer
3Verify spec, apply naming and classVerifikasi spesifikasi, terapkan naming dan kelas
ApproverApprover
4Approval gate by data ownerApproval gate oleh pemilik data
ERP / EAMERP / EAM
5Code created or updatedKode dibuat atau diperbarui
If steps 2 or 3 find an existing match, the request is returned with a link to the existing code instead of creating a new one.Jika langkah 2 atau 3 menemukan item yang cocok, request dikembalikan beserta tautan ke kode yang sudah ada, bukan dibuatkan kode baru.

Screening at source: catch it before it is typed inPenyaringan di sumber: tangkap sebelum sempat diinput

The cheapest duplicate is the one that is not submitted in the first place. Screening at source means the checks run while the requester is still filling in the form, so likely matches appear on screen and the requester can pick an existing code on the spot. Automated screening helps with volume; it surfaces candidates, while people still make the final call.Data dobel yang paling murah adalah yang tidak jadi diajukan. Penyaringan di sumber berarti pengecekan berjalan saat requester masih mengisi form, sehingga item yang kemungkinan cocok langsung muncul di layar dan requester bisa memilih kode yang sudah ada saat itu juga. Penyaringan otomatis membantu menangani volume; ia memunculkan kandidat, sementara keputusan akhir tetap di tangan manusia.

CheckPengecekan What it catchesYang ditangkap Typical actionTindakan umum
Part number matchKecocokan part number Same manufacturer part number already cataloguedPart number manufacturer yang sama sudah terkatalog Suggest the existing codeSarankan kode yang sudah ada
Attribute similarityKemiripan atribut Same class and key attributes under a different nameKelas dan atribut kunci sama dengan nama berbeda Flag for cataloguer reviewTandai untuk direview cataloguer
Text similarityKemiripan teks Near-identical wording or abbreviationsKata atau singkatan yang nyaris identik Show candidates to the requesterTampilkan kandidat ke requester
Template completenessKelengkapan template Missing mandatory attributesAtribut wajib yang belum diisi Return with guidance on what is missingKembalikan dengan petunjuk apa yang kurang
Class and UoM validityValiditas kelas dan satuan Wrong class or an unapproved unit of measureKelas yang keliru atau satuan yang tidak disetujui Correct before approvalPerbaiki sebelum approval

Cataloguer verification: the specialist in the middleVerifikasi cataloguer: spesialis di tengah alur

A trained cataloguer turns a request into a record that others can rely on. They check the specification against manufacturer data, apply the noun-modifier and naming convention, assign the class code, and decide whether a flagged candidate is truly a duplicate. When information is missing, they go back to the requester with a specific question rather than a generic rejection, which keeps the process moving and gradually improves the quality of incoming requests.Cataloguer yang terlatih mengubah request menjadi record yang bisa diandalkan orang lain. Mereka mencocokkan spesifikasi dengan data manufacturer, menerapkan noun-modifier dan naming convention, memberi kode kelas, dan memutuskan apakah kandidat yang ditandai memang benar-benar dobel. Jika ada informasi yang kurang, mereka kembali ke requester dengan pertanyaan spesifik, bukan penolakan umum, sehingga proses tetap berjalan dan kualitas request yang masuk perlahan membaik.

The approval gate: ownership before creationApproval gate: kepemilikan sebelum kode dibuat

The approval gate confirms that the right owner accepts the record before it becomes permanent. Depending on the item, that may be an engineer for technical accuracy on critical spares, the inventory team for stocking parameters, or procurement for vendor and sourcing details. Approvals work better when they are few and clearly assigned; too many sign-offs tend to push users back towards shortcuts.Approval gate memastikan pemilik yang tepat menerima record sebelum menjadi permanen. Tergantung itemnya, pemilik itu bisa engineer untuk ketepatan teknis spare part kritis, tim inventory untuk parameter stok, atau procurement untuk detail vendor dan sourcing. Approval lebih efektif jika jumlahnya sedikit dan jelas penanggung jawabnya; terlalu banyak tanda tangan justru mendorong user kembali mencari jalan pintas.

Speed matters here. Agreeing an SLA per request type, and an emergency lane for genuine breakdowns with a review after the fact, helps maintenance teams trust the process instead of working around it.Kecepatan penting di tahap ini. Menyepakati SLA untuk tiap jenis request, serta jalur darurat untuk breakdown yang benar-benar mendesak dengan review setelahnya, membantu tim maintenance memercayai proses alih-alih mengakalinya.

Fitting in with SAP, Maximo, Oracle or OdooMenyelaraskan dengan SAP, Maximo, Oracle, atau Odoo

The ERP or EAM remains the system of record. The Daily Cataloguing workflow sits in front of it as the single entry point, passing approved records through an interface or a controlled upload. The critical design decision is often organisational rather than technical: limit direct create and change rights in the ERP to a small, trained team, so the governed route is also the only route.ERP atau EAM tetap menjadi system of record. Workflow Daily Cataloguing berada di depannya sebagai satu-satunya pintu masuk, lalu meneruskan record yang sudah disetujui melalui interface atau upload yang terkontrol. Keputusan desain yang paling menentukan sering kali bersifat organisasi, bukan teknis: batasi hak create dan change langsung di ERP hanya untuk tim kecil yang terlatih, sehingga jalur yang dikelola juga menjadi satu-satunya jalur.

A governed route only works if it is also the easiest route.Jalur yang dikelola hanya efektif jika juga menjadi jalur yang paling mudah.

Designing a screening workflow for your ERP?Sedang merancang workflow penyaringan untuk ERP Anda?

Talk to us about roles, SLAs and approval gates that suit how your sites actually work.Bicarakan dengan kami soal peran, SLA, dan approval gate yang sesuai cara kerja site Anda.

Design the Workflow TogetherRancang Workflow Bersama

How to tell whether the gate is workingCara mengetahui apakah gerbangnya bekerja

Daily Cataloguing is measured by what it lets through and how quickly. A few indicators, reviewed monthly, give maintenance, procurement, IT and supply chain teams a shared view.Daily Cataloguing diukur dari apa yang diloloskannya dan seberapa cepat. Beberapa indikator yang direview setiap bulan memberi tim maintenance, procurement, IT, dan supply chain gambaran yang sama.

First-time-right rate shows how many requests pass without being returned, which reflects both template design and user training. Cycle time against SLA shows whether the process is fast enough for operations to trust it. Duplicates caught at screening versus duplicates found after creation tells you whether the filter sits in the right place. And the share of requests using the emergency lane reveals whether that lane is being used for real emergencies or as a shortcut.First-time-right rate menunjukkan berapa banyak request yang lolos tanpa dikembalikan, yang mencerminkan desain template sekaligus pelatihan user. Cycle time dibanding SLA menunjukkan apakah proses cukup cepat untuk dipercaya tim operasi. Data dobel yang tertangkap saat penyaringan dibanding data dobel yang ditemukan setelah kode dibuat memberi tahu apakah saringannya berada di posisi yang tepat. Sementara itu, porsi request yang memakai jalur darurat memperlihatkan apakah jalur itu dipakai untuk keadaan darurat sungguhan atau justru sebagai jalan pintas.

Tracked over time, these measures turn the conversation from "the data is messy again" into specific, fixable questions about templates, rights and response times.Jika dipantau dari waktu ke waktu, indikator ini mengubah keluhan "datanya berantakan lagi" menjadi pertanyaan spesifik yang bisa ditindaklanjuti, yaitu soal template, hak akses, dan waktu respons.

Key TakeawaysPoin Penting

  • Clean data decays because the catalogue keeps changing; quality reflects every transaction since the baseline.Data bersih bisa merosot karena katalog terus berubah; kualitasnya mencerminkan setiap transaksi sejak baseline.
  • Govern all four request types. Read before Create, protect meaning during Change, and retire rather than remove on Delete.Kelola keempat jenis request. Read sebelum Create, jaga makna saat Change, dan nonaktifkan, bukan hapus, saat Delete.
  • Screen at source so likely duplicates appear while the requester is still filling in the form.Saring di sumber agar kandidat data dobel muncul saat requester masih mengisi form.
  • Pair cataloguer verification with a small, clearly owned approval gate and a realistic SLA.Padukan verifikasi cataloguer dengan approval gate yang ringkas, pemilik yang jelas, dan SLA yang realistis.
  • Make the governed route the only route by limiting direct create and change rights in the ERP or EAM.Jadikan jalur yang dikelola sebagai satu-satunya jalur dengan membatasi hak create dan change langsung di ERP atau EAM.