On Monday morning, a technician needs a mechanical seal for a slurry pump. He searches the ERP using the words he would normally use, and nothing comes up. So he does what the system allows: he raises a new item. By Thursday, Procurement has issued a purchase order. The following week, a second box of the same seal sits two bays away from the first.Senin pagi, seorang teknisi butuh mechanical seal untuk pompa slurry. Ia mencari di ERP dengan kata yang biasa ia pakai, dan hasilnya kosong. Jadi ia melakukan apa yang diizinkan sistem: membuat item baru. Kamis, procurement sudah menerbitkan PO. Minggu berikutnya, satu kotak seal yang sama sudah tersimpan dua rak dari kotak yang lama.
Nobody broke a rule. The technician searched. The buyer bought what was requested. The warehouse received what arrived. The problem is that, at the moment the new item was created, there was no rule to break. The request went straight into the ERP without anyone, or anything, checking it against what already existed.Tidak ada yang melanggar aturan. Teknisi sudah mencari. Buyer membeli sesuai request. Gudang menerima barang yang datang. Masalahnya, saat item baru itu dibuat, memang belum ada aturan yang bisa dilanggar. Request langsung masuk ke ERP tanpa dicek oleh siapa pun, atau apa pun, terhadap data yang sudah ada.
That moment is where many duplicate spare parts begin, long before they show up as excess stock. So the useful question for operations and Supply Chain leaders is not who should clean up the item master. It is who owns the moment a new stock item is created, and what should happen before a code is issued.Di titik itulah banyak spare part dobel bermula, jauh sebelum terlihat sebagai stok berlebih. Karena itu, pertanyaan yang lebih berguna bagi pimpinan operasional dan Supply Chain bukan siapa yang harus membereskan item master. Pertanyaannya: siapa pemilik momen saat stock item baru dibuat, dan apa yang perlu terjadi sebelum kodenya diterbitkan?
The gap: a request that reaches the ERP uncheckedCelahnya: request yang masuk ke ERP tanpa dicek
In many plants, creating a new material code is treated as an administrative step. Someone fills in a form, a key user or master data clerk keys it in, and the ERP issues the next number. The ERP does what it is designed to do: it checks mandatory fields, formats and number ranges. It is not usually set up to judge whether the part being described already exists under another name.Di banyak plant, pembuatan kode material baru dianggap langkah administratif. Seseorang mengisi formulir, key user atau staf master data menginputnya, lalu ERP menerbitkan nomor berikutnya. ERP bekerja sesuai rancangannya: mengecek field wajib, format, dan rentang nomor. Tapi ERP umumnya tidak diatur untuk menilai apakah part yang dideskripsikan sebenarnya sudah ada dengan nama lain.
That judgement depends on search, and search depends on how people describe things. One person types "seal pump", another types "mech seal", a third pastes a manufacturer part number with the dashes removed. The existing record may read SEAL, MECHANICAL, with the part number stored in a long text field. Each search is reasonable. None of them is sure to find the match.Penilaian itu bergantung pada pencarian, dan pencarian bergantung pada cara orang mendeskripsikan barang. Satu orang mengetik "seal pump", yang lain "mech seal", yang ketiga menempelkan part number manufacturer tanpa tanda strip. Sementara record yang sudah ada tertulis SEAL, MECHANICAL, dengan part number tersimpan di long text. Semua pencarian itu masuk akal, tapi tidak satu pun yang pasti menemukan kecocokan.
So a "no results" screen gets read as "this part does not exist", when it often means "nothing matches these words". The distance between those two meanings is exactly where the second code enters the system.Akibatnya, layar "tidak ada hasil" dibaca sebagai "part ini belum ada", padahal sering artinya hanya "tidak ada yang cocok dengan kata kunci ini". Jarak antara dua arti itulah pintu masuk kode kedua ke dalam sistem.
Why individual diligence is not enoughKenapa ketelitian individu saja tidak cukup
Asking technicians to search harder rarely closes the gap. They are measured on getting equipment back into service, not on the quality of the item master, and the pressure of an open work order tends to win. A safeguard that depends on every requester searching perfectly, every time, on every shift, is not really a control. It is a hope.Meminta teknisi mencari lebih teliti jarang menutup celah ini. Kinerja mereka diukur dari seberapa cepat mesin kembali beroperasi, bukan dari kualitas item master, dan tekanan work order yang masih terbuka biasanya menang. Pengaman yang bergantung pada setiap requester mencari dengan sempurna, setiap saat, di setiap shift, sebenarnya bukan kontrol. Itu harapan.
The same applies to key users who enter requests on behalf of others. They see the request as written, often without the equipment context, and they are usually working through a queue. Without a structured check at the point of entry, the quality of the item master ends up resting on the busiest people in the process.Hal yang sama berlaku untuk key user yang menginput request atas nama orang lain. Mereka hanya melihat request apa adanya, sering tanpa konteks peralatan, dan biasanya sedang mengejar antrean. Tanpa pengecekan yang terstruktur di pintu masuk, kualitas item master akhirnya bertumpu pada orang-orang yang paling sibuk dalam proses.
Why it is a leadership issue, not a data-entry issueKenapa ini urusan pimpinan, bukan sekadar urusan input data
A duplicate code is hard to see on the day it is created. It looks like any other new item: a valid number, a sensible description, a requester with a real need. It only becomes visible later, once it has a code, a purchase order and stock on a shelf. By then it has already started to cost money, and it is harder to unwind.Kode dobel sulit terlihat pada hari ia dibuat. Tampilannya sama seperti item baru lainnya: nomornya valid, deskripsinya masuk akal, dan requester-nya memang butuh barang itu. Kode tersebut baru kelihatan belakangan, setelah punya kode, PO, dan stok di rak. Saat itu biayanya sudah berjalan, dan membereskannya jadi lebih rumit.
From there, the effects spread across functions that rarely look at the same report:Dari situ, dampaknya menyebar ke fungsi-fungsi yang jarang membaca laporan yang sama:
- Inventory: the same part sits under two codes, each with its own reorder point, so combined stock can drift above what the plant needs.Inventory: part yang sama tersimpan dengan dua kode, masing-masing punya reorder point sendiri, sehingga total stok bisa melebihi kebutuhan plant.
- Procurement: demand for one part is split across codes, which makes total volume harder to see and harder to negotiate on.Procurement: kebutuhan untuk satu part terpecah ke beberapa kode, sehingga total volume sulit terlihat dan posisi tawar ke vendor melemah.
- Maintenance: a planner may reserve the code with no stock and wait for a delivery while the same part is sitting on another shelf.Maintenance: planner bisa saja me-reserve kode yang stoknya kosong lalu menunggu pengiriman, padahal part yang sama ada di rak lain.
- Finance: slow-moving stock grows quietly, and later write-off decisions become harder to explain.Finance: stok slow-moving bertambah diam-diam, dan keputusan write-off di kemudian hari makin sulit dijelaskan.
Each function sees a symptom. None of them owns the cause, because the cause sits at a step that belongs to no one in particular. That is what makes it a leadership issue. A cleansing project can reduce the backlog, but if the entry point stays open, new duplicates tend to keep arriving through the same route.Setiap fungsi melihat gejalanya, tapi tidak ada yang memegang akar masalahnya, karena akarnya ada di langkah yang tidak jelas pemiliknya. Itulah yang menjadikannya urusan pimpinan. Proyek cleansing bisa mengurangi tumpukan data dobel, tapi selama pintu masuknya tetap terbuka, kode dobel baru cenderung terus masuk lewat jalur yang sama.
| StageTahap | What happensYang terjadi | Who usually noticesSiapa yang biasanya sadar |
|---|---|---|
| RequestRequest | The search finds no match, so a new item is raisedPencarian tidak menemukan hasil, lalu item baru diajukan | Usually no oneBiasanya tidak ada |
| Code issuedKode terbit | The ERP assigns a new number to a valid-looking recordERP memberi nomor baru pada record yang tampak valid | Usually no oneBiasanya tidak ada |
| Purchase orderPO | The buyer orders against the new codeBuyer memesan dengan kode baru | Sometimes the buyer, if the vendor or price looks familiarKadang buyer, jika vendor atau harganya terasa familier |
| ReceiptPenerimaan | Goods arrive and are stored under the new codeBarang datang dan disimpan dengan kode baru | Sometimes the warehouseKadang tim gudang |
| Stock reviewReview stok | Two codes, combined stock above needDua kode, total stok di atas kebutuhan | Inventory or Finance, often months laterInventory atau Finance, sering berbulan-bulan kemudian |
Conceptual illustration, not based on measured data. The pattern varies by organisation.Ilustrasi konseptual, bukan hasil pengukuran. Polanya bisa berbeda di tiap organisasi.
Notice where visibility starts: well after the decision that created the problem. The earlier a check happens, the cheaper it tends to be. A question asked before a code exists costs a few minutes. The same question asked after a purchase order and a goods receipt can involve returns, stock transfers, reservation changes and a conversation about who pays for what.Perhatikan kapan masalahnya mulai terlihat: jauh setelah keputusan yang memicunya. Semakin awal pengecekan dilakukan, biayanya cenderung semakin murah. Pertanyaan yang diajukan sebelum kode terbit hanya butuh beberapa menit. Pertanyaan yang sama setelah PO dan penerimaan barang bisa berujung pada retur, transfer stok, perubahan reservasi, dan diskusi soal siapa yang menanggung biayanya.
Where are new item requests checked today?Di mana request item baru dicek saat ini?
Let's map the path a request takes from work order to ERP code.Mari petakan jalur request, dari work order sampai jadi kode di ERP.
Item creation is a decision: it needs an owner, a gate and a recordPembuatan item adalah keputusan: butuh pemilik, gerbang, dan catatan
If item creation is a decision rather than a keystroke, it deserves the same structure as other operational decisions. Three elements matter most.Jika pembuatan item adalah keputusan dan bukan sekadar ketikan, ia layak diperlakukan seperti keputusan operasional lainnya. Ada tiga elemen yang paling menentukan.
- An owner. A named function accountable for the rules of how items enter the master. This is not necessarily the person who keys them in. Without an owner, the step defaults to whoever is fastest.Pemilik. Fungsi yang ditunjuk dan bertanggung jawab atas aturan masuknya item ke master data. Tidak harus orang yang menginputnya. Tanpa pemilik, langkah ini otomatis jatuh ke siapa pun yang paling cepat.
- A gate. One point that every request passes through, where it is checked against what already exists before a code is issued.Gerbang. Satu titik yang wajib dilewati setiap request, tempat request dicek terhadap data yang sudah ada sebelum kode diterbitkan.
- A record. A trail of who requested, what was checked, who approved and why. It turns "who created this code?" from an argument into a lookup.Catatan. Jejak tentang siapa yang mengajukan, apa yang dicek, siapa yang menyetujui, dan alasannya. Pertanyaan "siapa yang bikin kode ini?" tidak lagi jadi bahan debat, cukup dilihat di riwayat.
None of this asks the technician to become a data specialist. It changes where the check happens: from one person's search screen to a governed step that sits between the request and the ERP. The requester still describes what they need. The organisation takes responsibility for confirming whether it is new.Semua ini tidak menuntut teknisi menjadi ahli data. Yang berubah adalah lokasi pengecekannya: dari layar pencarian satu orang ke langkah yang tertata di antara request dan ERP. Requester tetap menjelaskan kebutuhannya, sementara organisasi yang memastikan apakah barang itu memang baru.
The duplicate is decided at registration. The warehouse only stores the result.Kode dobel diputuskan saat registrasi. Gudang hanya menyimpan hasilnya.
The operating model: one governed entry pointModel operasional: satu pintu masuk yang tertata
The operating model is simple to describe. Every request to Create, Change or Delete a material goes through one governed entry point, instead of reaching the ERP by different routes such as email, spreadsheets, direct entry by key users or tickets to IT. The ERP remains the system of record. The entry point becomes the place where requests are screened, routed and approved before anything is written to it.Model operasionalnya sederhana. Setiap request untuk Create, Change, atau Delete material masuk lewat satu pintu yang tertata, bukan lewat banyak jalur seperti email, spreadsheet, input langsung oleh key user, atau tiket ke IT. ERP tetap menjadi system of record. Pintu masuk inilah tempat request disaring, diarahkan, dan disetujui sebelum ada data yang ditulis ke ERP.
Change and Delete deserve the same discipline as Create. A change to a part number or a key attribute can quietly turn a correct record into a misleading one. A deletion or block can leave reservations or work orders pointing at a code that no longer behaves as people expect. Bringing all three through one door keeps the rules, and the record, consistent.Change dan Delete perlu disiplin yang sama dengan Create. Perubahan part number atau atribut kunci bisa diam-diam mengubah record yang benar menjadi menyesatkan. Penghapusan atau block bisa membuat reservasi atau work order mengarah ke kode yang tidak lagi berfungsi seperti yang diharapkan. Dengan menyatukan ketiganya dalam satu pintu, aturan dan catatannya tetap konsisten.
From request to ERP: one entry point, one screen, four approversDari request ke ERP: satu pintu, satu penyaringan, empat pemberi approval
- Request raised A requester submits a Create, Change or Delete request with the details they have.Request diajukan Requester mengajukan request Create, Change, atau Delete dengan detail yang ia punya.
- Single entry point All requests arrive in one governed queue, not via email, spreadsheets or direct ERP entry.Satu pintu masuk Semua request masuk ke satu antrean yang tertata, bukan lewat email, spreadsheet, atau input langsung ke ERP.
- Screening The request is checked against existing part numbers and attributes before any code is issued.Penyaringan Request dicek terhadap part number dan atribut yang sudah ada sebelum kode apa pun diterbitkan.
- Role-based approval The relevant functions review the request and record their decision.Approval berbasis peran Fungsi terkait me-review request dan mencatat keputusannya.
WarehouseGudangProcurementProcurementMaintenanceMaintenanceITIT
- ERP update and audit trail The approved code or change is applied in the ERP, with every decision kept on record.Update ERP dan audit trail Kode atau perubahan yang disetujui diterapkan di ERP, dan setiap keputusan tetap tercatat.
Conceptual illustration, not based on measured data. Routing and sequence can differ by request type and organisation.Ilustrasi konseptual, bukan hasil pengukuran. Alur dan urutan approval bisa berbeda menurut jenis request dan organisasi.
The three request types carry different risks, so it helps to be explicit about what reviewers need to confirm for each one.Ketiga jenis request membawa risiko yang berbeda, jadi sebaiknya jelas apa yang perlu dipastikan reviewer untuk masing-masing.
| Request typeJenis request | Risk without a gateRisiko tanpa gerbang | What reviewers need to confirmYang perlu dipastikan reviewer |
|---|---|---|
| CreateCreate | A second code for a part that already existsKode kedua untuk part yang sebenarnya sudah ada | The part is not already held under another codePart tersebut belum tercatat dengan kode lain |
| ChangeChange | A key attribute altered without the code's users knowingAtribut kunci berubah tanpa diketahui pengguna kode itu | The change is correct and affected functions are awarePerubahannya benar dan fungsi terkait sudah tahu |
| DeleteDelete | A code removed or blocked while stock or open demand still refers to itKode dihapus atau di-block padahal masih ada stok atau kebutuhan terbuka | Nothing is left pointing at the codeTidak ada lagi yang masih mengacu ke kode itu |
How the gate works, brieflyCara kerja gerbangnya, secara singkat
The gate does not need to be complicated to be useful. Before a code is issued, each request is screened against what is already in the master: the manufacturer part number, and the attributes that describe the item, such as type, size, material or rating.Gerbangnya tidak perlu rumit untuk bisa berguna. Sebelum kode terbit, setiap request disaring terhadap isi master data yang sudah ada: part number manufacturer dan atribut yang mendeskripsikan item, misalnya jenis, ukuran, material, atau rating.
Screening on both matters. A part number is often the strongest signal, but it is not always captured, and it may be stored in different formats. Attributes help surface matches that a description alone could miss, for example when the same bearing is recorded once as BRG, BALL 6205 2RS and once in free text by a different team.Keduanya perlu dicek. Part number sering jadi petunjuk paling kuat, tapi tidak selalu diisi dan formatnya bisa berbeda-beda. Atribut membantu memunculkan kecocokan yang bisa terlewat jika hanya mengandalkan deskripsi, misalnya ketika bearing yang sama tercatat sebagai BRG, BALL 6205 2RS di satu record dan sebagai teks bebas oleh tim lain.
When a likely match is foundJika ada kemungkinan kecocokan
The request is held, and reviewers see the existing record alongside the new one.Request ditahan, dan reviewer melihat record lama berdampingan dengan request baru.
- Requester can be pointed to the existing codeRequester bisa diarahkan ke kode yang sudah ada
- Helps avoid a second code and second POMembantu mencegah kode kedua dan PO kedua
- Decision and reason are recordedKeputusan dan alasannya tercatat
When no match is foundJika tidak ada kecocokan
The request moves on to the approving functions with its screening result attached.Request lanjut ke fungsi pemberi approval, lengkap dengan hasil penyaringannya.
- Approvers see what was checkedApprover bisa melihat apa saja yang sudah dicek
- Description and attributes are reviewedDeskripsi dan atribut di-review
- Code is issued only after approvalKode baru terbit setelah disetujui
The point is not that screening will catch every possible duplicate. It is that every request is checked in the same way, at the same place, before it becomes a code, rather than depending on how well one person searched on one busy morning.Intinya bukan bahwa penyaringan akan menangkap semua kemungkinan kode dobel. Intinya, setiap request dicek dengan cara yang sama, di tempat yang sama, sebelum menjadi kode, alih-alih bergantung pada seberapa teliti satu orang mencari di satu pagi yang sibuk.
Who approves: four functions, one recordSiapa yang menyetujui: empat fungsi, satu catatan
Screening answers the question "does this already exist?". Approval answers a different one: "should this exist, and is it described correctly?". That is a judgement no single function can make well on its own, which is why a role-based workflow tends to work better than a single gatekeeper.Penyaringan menjawab pertanyaan "apakah barang ini sudah ada?". Approval menjawab pertanyaan lain: "apakah item ini memang perlu ada, dan apakah deskripsinya sudah benar?". Penilaian seperti itu sulit dilakukan dengan baik oleh satu fungsi saja, sehingga workflow berbasis peran cenderung lebih efektif daripada satu penjaga gerbang tunggal.
| FunctionFungsi | What it typically confirmsYang biasanya dipastikan |
|---|---|
| WarehouseGudang | Whether the part is already held, and how it will be stored and identified on the shelfApakah part sudah ada di stok, serta bagaimana penyimpanan dan identifikasinya di rak |
| ProcurementProcurement | Whether the part can be sourced as described, and whether it overlaps with items already being purchasedApakah part bisa dibeli sesuai deskripsi, dan apakah tumpang tindih dengan item yang sudah rutin dibeli |
| MaintenanceMaintenance | Whether the part is technically right for the equipment, and how critical it isApakah part secara teknis sesuai untuk peralatannya, dan seberapa kritis perannya |
| ITIT | Whether the record meets system and data standards before it is written to the ERPApakah record sudah memenuhi standar sistem dan data sebelum ditulis ke ERP |
Typical responsibilities. Exact roles and sequence depend on your organisation's policy.Tanggung jawab yang umum. Peran dan urutan pastinya bergantung pada kebijakan organisasi Anda.
Every decision along the way is recorded in an audit trail: who requested, what the screening showed, who approved or rejected, and when. That record has practical value. When someone later asks why two similar codes exist, or why a request was turned down, the answer sits in the history rather than in someone's memory or inbox.Setiap keputusan di sepanjang alur tercatat dalam audit trail: siapa yang mengajukan, apa hasil penyaringannya, siapa yang menyetujui atau menolak, dan kapan. Catatan ini punya nilai praktis. Ketika suatu hari ada yang bertanya kenapa ada dua kode yang mirip, atau kenapa sebuah request ditolak, jawabannya ada di riwayat, bukan di ingatan seseorang atau di kotak masuk email.
It also gives leaders something they rarely have today: visibility of how items enter the master. How many requests arrive, how many were matched to existing codes, and where approvals tend to wait all become questions you can answer once requests flow through one door. That is the difference between hoping the item master stays clean and being able to see whether it does.Catatan ini juga memberi pimpinan sesuatu yang jarang mereka punya: visibilitas tentang bagaimana item masuk ke master data. Berapa banyak request yang masuk, berapa yang ternyata cocok dengan kode lama, dan di mana approval sering tertahan, semuanya bisa dijawab begitu request mengalir lewat satu pintu. Bedanya jelas: dari sekadar berharap item master tetap rapi, menjadi bisa melihat apakah memang rapi.
How would a governed flow fit your ERP?Bagaimana alur yang tertata ini cocok dengan ERP Anda?
We can walk through Create, Change and Delete requests using your own roles.Kita bisa telusuri request Create, Change, dan Delete dengan peran di tim Anda sendiri.
A note on the name ANSICatatan soal nama ANSI
In this article, ANSI refers to SCS®-ANSI Module, Panemu's master data governance application. It is not the American National Standards Institute, and it is not related to ANSI standards for parts or materials.Dalam artikel ini, ANSI merujuk pada SCS®-ANSI Module, aplikasi tata kelola master data dari Panemu. ANSI di sini bukan American National Standards Institute, dan tidak berkaitan dengan standar ANSI untuk part atau material.
ANSI is designed to help organisations run the governed entry point described above: one place for Create, Change and Delete requests, screening against existing part numbers and attributes before a code is issued, and a role-based approval workflow across Warehouse, Procurement, Maintenance and IT, with each decision kept in an audit trail.ANSI dirancang untuk membantu organisasi menjalankan pintu masuk tertata seperti yang dijelaskan di atas: satu tempat untuk request Create, Change, dan Delete, penyaringan terhadap part number dan atribut yang sudah ada sebelum kode terbit, serta workflow approval berbasis peran yang melibatkan Gudang, Procurement, Maintenance, dan IT, dengan setiap keputusan tersimpan di audit trail.
Where to start: five questions for leadershipMulai dari mana: lima pertanyaan untuk pimpinan
Before choosing tools, it helps to agree on the decision itself. These questions can frame a first conversation between Operations, Supply Chain, Maintenance and IT.Sebelum memilih tools, ada baiknya sepakat dulu soal keputusannya. Pertanyaan berikut bisa jadi bahan diskusi awal antara Operasional, Supply Chain, Maintenance, dan IT.
- Map the routes. How many ways can a new item reach your ERP today? Count email, spreadsheets, key-user entry and IT tickets.Petakan jalurnya. Ada berapa cara item baru bisa masuk ke ERP Anda saat ini? Hitung email, spreadsheet, input oleh key user, dan tiket ke IT.
- Name the owner. Which function is accountable for the rules of item creation, as distinct from the people who key it in?Tunjuk pemiliknya. Fungsi mana yang bertanggung jawab atas aturan pembuatan item, terpisah dari orang yang menginputnya?
- Define the gate. What must be checked before a code is issued, and what happens when a likely match turns up?Tentukan gerbangnya. Apa yang wajib dicek sebelum kode terbit, dan apa yang terjadi jika muncul kemungkinan kecocokan?
- Agree the approvers. Which functions sign off on Create, Change and Delete, and in what order?Sepakati approver-nya. Fungsi mana yang memberi approval untuk Create, Change, dan Delete, dan bagaimana urutannya?
- Decide what to record. What will you need to see in six months, when someone asks why a code exists?Putuskan apa yang dicatat. Informasi apa yang Anda butuhkan enam bulan lagi, saat ada yang bertanya kenapa sebuah kode ada?
Treat these as a starting point for discussion rather than a diagnosis. The right answers depend on your plant structure, your ERP set-up and how centralised your master data team is. A multi-site operation may need local approvers with a central owner. A single plant may combine roles. What matters is that the answers are written down and that every request follows them.Anggap pertanyaan ini sebagai titik awal diskusi, bukan diagnosis. Jawaban yang tepat bergantung pada struktur plant, konfigurasi ERP, dan seberapa terpusat tim master data Anda. Operasi multi-site mungkin butuh approver lokal dengan satu pemilik pusat, sementara satu plant bisa saja menggabungkan beberapa peran. Yang penting, jawabannya tertulis dan setiap request mengikutinya.
Ready to give item creation a clear owner?Siap memberi pemilik yang jelas untuk pembuatan item?
Talk to us about one governed entry point for your material master.Diskusikan satu pintu masuk yang tertata untuk Material Master Data Anda.
Key TakeawaysPoin Penting
- Many duplicate spare parts begin at registration, when a request reaches the ERP without being checked against what already exists.Banyak spare part dobel bermula saat registrasi, ketika request masuk ke ERP tanpa dicek terhadap data yang sudah ada.
- A "no results" search often means "no match for these words", not "this part does not exist".Hasil pencarian "tidak ditemukan" sering berarti "tidak cocok dengan kata kunci ini", bukan "part ini belum ada".
- The duplicate tends to become visible only after it has a code and a purchase order, which is why it needs leadership ownership.Kode dobel cenderung baru terlihat setelah punya kode dan PO, karena itu perlu pemilik di level pimpinan.
- Treat item creation as a decision with an owner, a gate and a record.Perlakukan pembuatan item sebagai keputusan yang punya pemilik, gerbang, dan catatan.
- Route Create, Change and Delete through one governed entry point, screen against part numbers and attributes, and approve through Warehouse, Procurement, Maintenance and IT with an audit trail.Arahkan Create, Change, dan Delete lewat satu pintu masuk yang tertata, saring terhadap part number dan atribut, lalu proses approval lewat Gudang, Procurement, Maintenance, dan IT dengan audit trail.
On Monday morning, a technician needs a mechanical seal for a slurry pump. He searches the ERP using the words he would normally use, and nothing comes up. So he does what the system allows: he raises a new item. By Thursday, Procurement has issued a purchase order. The following week, a second box of the same seal sits two bays away from the first.Senin pagi, seorang teknisi butuh mechanical seal untuk pompa slurry. Ia mencari di ERP dengan kata yang biasa ia pakai, dan hasilnya kosong. Jadi ia melakukan apa yang diizinkan sistem: membuat item baru. Kamis, procurement sudah menerbitkan PO. Minggu berikutnya, satu kotak seal yang sama sudah tersimpan dua rak dari kotak yang lama.
Nobody broke a rule. The technician searched. The buyer bought what was requested. The warehouse received what arrived. The problem is that, at the moment the new item was created, there was no rule to break. The request went straight into the ERP without anyone, or anything, checking it against what already existed.Tidak ada yang melanggar aturan. Teknisi sudah mencari. Buyer membeli sesuai request. Gudang menerima barang yang datang. Masalahnya, saat item baru itu dibuat, memang belum ada aturan yang bisa dilanggar. Request langsung masuk ke ERP tanpa dicek oleh siapa pun, atau apa pun, terhadap data yang sudah ada.
That moment is where many duplicate spare parts begin, long before they show up as excess stock. So the useful question for operations and Supply Chain leaders is not who should clean up the item master. It is who owns the moment a new stock item is created, and what should happen before a code is issued.Di titik itulah banyak spare part dobel bermula, jauh sebelum terlihat sebagai stok berlebih. Karena itu, pertanyaan yang lebih berguna bagi pimpinan operasional dan Supply Chain bukan siapa yang harus membereskan item master. Pertanyaannya: siapa pemilik momen saat stock item baru dibuat, dan apa yang perlu terjadi sebelum kodenya diterbitkan?
The gap: a request that reaches the ERP uncheckedCelahnya: request yang masuk ke ERP tanpa dicek
In many plants, creating a new material code is treated as an administrative step. Someone fills in a form, a key user or master data clerk keys it in, and the ERP issues the next number. The ERP does what it is designed to do: it checks mandatory fields, formats and number ranges. It is not usually set up to judge whether the part being described already exists under another name.Di banyak plant, pembuatan kode material baru dianggap langkah administratif. Seseorang mengisi formulir, key user atau staf master data menginputnya, lalu ERP menerbitkan nomor berikutnya. ERP bekerja sesuai rancangannya: mengecek field wajib, format, dan rentang nomor. Tapi ERP umumnya tidak diatur untuk menilai apakah part yang dideskripsikan sebenarnya sudah ada dengan nama lain.
That judgement depends on search, and search depends on how people describe things. One person types "seal pump", another types "mech seal", a third pastes a manufacturer part number with the dashes removed. The existing record may read SEAL, MECHANICAL, with the part number stored in a long text field. Each search is reasonable. None of them is sure to find the match.Penilaian itu bergantung pada pencarian, dan pencarian bergantung pada cara orang mendeskripsikan barang. Satu orang mengetik "seal pump", yang lain "mech seal", yang ketiga menempelkan part number manufacturer tanpa tanda strip. Sementara record yang sudah ada tertulis SEAL, MECHANICAL, dengan part number tersimpan di long text. Semua pencarian itu masuk akal, tapi tidak satu pun yang pasti menemukan kecocokan.
So a "no results" screen gets read as "this part does not exist", when it often means "nothing matches these words". The distance between those two meanings is exactly where the second code enters the system.Akibatnya, layar "tidak ada hasil" dibaca sebagai "part ini belum ada", padahal sering artinya hanya "tidak ada yang cocok dengan kata kunci ini". Jarak antara dua arti itulah pintu masuk kode kedua ke dalam sistem.
Why individual diligence is not enoughKenapa ketelitian individu saja tidak cukup
Asking technicians to search harder rarely closes the gap. They are measured on getting equipment back into service, not on the quality of the item master, and the pressure of an open work order tends to win. A safeguard that depends on every requester searching perfectly, every time, on every shift, is not really a control. It is a hope.Meminta teknisi mencari lebih teliti jarang menutup celah ini. Kinerja mereka diukur dari seberapa cepat mesin kembali beroperasi, bukan dari kualitas item master, dan tekanan work order yang masih terbuka biasanya menang. Pengaman yang bergantung pada setiap requester mencari dengan sempurna, setiap saat, di setiap shift, sebenarnya bukan kontrol. Itu harapan.
The same applies to key users who enter requests on behalf of others. They see the request as written, often without the equipment context, and they are usually working through a queue. Without a structured check at the point of entry, the quality of the item master ends up resting on the busiest people in the process.Hal yang sama berlaku untuk key user yang menginput request atas nama orang lain. Mereka hanya melihat request apa adanya, sering tanpa konteks peralatan, dan biasanya sedang mengejar antrean. Tanpa pengecekan yang terstruktur di pintu masuk, kualitas item master akhirnya bertumpu pada orang-orang yang paling sibuk dalam proses.
Why it is a leadership issue, not a data-entry issueKenapa ini urusan pimpinan, bukan sekadar urusan input data
A duplicate code is hard to see on the day it is created. It looks like any other new item: a valid number, a sensible description, a requester with a real need. It only becomes visible later, once it has a code, a purchase order and stock on a shelf. By then it has already started to cost money, and it is harder to unwind.Kode dobel sulit terlihat pada hari ia dibuat. Tampilannya sama seperti item baru lainnya: nomornya valid, deskripsinya masuk akal, dan requester-nya memang butuh barang itu. Kode tersebut baru kelihatan belakangan, setelah punya kode, PO, dan stok di rak. Saat itu biayanya sudah berjalan, dan membereskannya jadi lebih rumit.
From there, the effects spread across functions that rarely look at the same report:Dari situ, dampaknya menyebar ke fungsi-fungsi yang jarang membaca laporan yang sama:
- Inventory: the same part sits under two codes, each with its own reorder point, so combined stock can drift above what the plant needs.Inventory: part yang sama tersimpan dengan dua kode, masing-masing punya reorder point sendiri, sehingga total stok bisa melebihi kebutuhan plant.
- Procurement: demand for one part is split across codes, which makes total volume harder to see and harder to negotiate on.Procurement: kebutuhan untuk satu part terpecah ke beberapa kode, sehingga total volume sulit terlihat dan posisi tawar ke vendor melemah.
- Maintenance: a planner may reserve the code with no stock and wait for a delivery while the same part is sitting on another shelf.Maintenance: planner bisa saja me-reserve kode yang stoknya kosong lalu menunggu pengiriman, padahal part yang sama ada di rak lain.
- Finance: slow-moving stock grows quietly, and later write-off decisions become harder to explain.Finance: stok slow-moving bertambah diam-diam, dan keputusan write-off di kemudian hari makin sulit dijelaskan.
Each function sees a symptom. None of them owns the cause, because the cause sits at a step that belongs to no one in particular. That is what makes it a leadership issue. A cleansing project can reduce the backlog, but if the entry point stays open, new duplicates tend to keep arriving through the same route.Setiap fungsi melihat gejalanya, tapi tidak ada yang memegang akar masalahnya, karena akarnya ada di langkah yang tidak jelas pemiliknya. Itulah yang menjadikannya urusan pimpinan. Proyek cleansing bisa mengurangi tumpukan data dobel, tapi selama pintu masuknya tetap terbuka, kode dobel baru cenderung terus masuk lewat jalur yang sama.
| StageTahap | What happensYang terjadi | Who usually noticesSiapa yang biasanya sadar |
|---|---|---|
| RequestRequest | The search finds no match, so a new item is raisedPencarian tidak menemukan hasil, lalu item baru diajukan | Usually no oneBiasanya tidak ada |
| Code issuedKode terbit | The ERP assigns a new number to a valid-looking recordERP memberi nomor baru pada record yang tampak valid | Usually no oneBiasanya tidak ada |
| Purchase orderPO | The buyer orders against the new codeBuyer memesan dengan kode baru | Sometimes the buyer, if the vendor or price looks familiarKadang buyer, jika vendor atau harganya terasa familier |
| ReceiptPenerimaan | Goods arrive and are stored under the new codeBarang datang dan disimpan dengan kode baru | Sometimes the warehouseKadang tim gudang |
| Stock reviewReview stok | Two codes, combined stock above needDua kode, total stok di atas kebutuhan | Inventory or Finance, often months laterInventory atau Finance, sering berbulan-bulan kemudian |
Conceptual illustration, not based on measured data. The pattern varies by organisation.Ilustrasi konseptual, bukan hasil pengukuran. Polanya bisa berbeda di tiap organisasi.
Notice where visibility starts: well after the decision that created the problem. The earlier a check happens, the cheaper it tends to be. A question asked before a code exists costs a few minutes. The same question asked after a purchase order and a goods receipt can involve returns, stock transfers, reservation changes and a conversation about who pays for what.Perhatikan kapan masalahnya mulai terlihat: jauh setelah keputusan yang memicunya. Semakin awal pengecekan dilakukan, biayanya cenderung semakin murah. Pertanyaan yang diajukan sebelum kode terbit hanya butuh beberapa menit. Pertanyaan yang sama setelah PO dan penerimaan barang bisa berujung pada retur, transfer stok, perubahan reservasi, dan diskusi soal siapa yang menanggung biayanya.
Where are new item requests checked today?Di mana request item baru dicek saat ini?
Let's map the path a request takes from work order to ERP code.Mari petakan jalur request, dari work order sampai jadi kode di ERP.
Item creation is a decision: it needs an owner, a gate and a recordPembuatan item adalah keputusan: butuh pemilik, gerbang, dan catatan
If item creation is a decision rather than a keystroke, it deserves the same structure as other operational decisions. Three elements matter most.Jika pembuatan item adalah keputusan dan bukan sekadar ketikan, ia layak diperlakukan seperti keputusan operasional lainnya. Ada tiga elemen yang paling menentukan.
- An owner. A named function accountable for the rules of how items enter the master. This is not necessarily the person who keys them in. Without an owner, the step defaults to whoever is fastest.Pemilik. Fungsi yang ditunjuk dan bertanggung jawab atas aturan masuknya item ke master data. Tidak harus orang yang menginputnya. Tanpa pemilik, langkah ini otomatis jatuh ke siapa pun yang paling cepat.
- A gate. One point that every request passes through, where it is checked against what already exists before a code is issued.Gerbang. Satu titik yang wajib dilewati setiap request, tempat request dicek terhadap data yang sudah ada sebelum kode diterbitkan.
- A record. A trail of who requested, what was checked, who approved and why. It turns "who created this code?" from an argument into a lookup.Catatan. Jejak tentang siapa yang mengajukan, apa yang dicek, siapa yang menyetujui, dan alasannya. Pertanyaan "siapa yang bikin kode ini?" tidak lagi jadi bahan debat, cukup dilihat di riwayat.
None of this asks the technician to become a data specialist. It changes where the check happens: from one person's search screen to a governed step that sits between the request and the ERP. The requester still describes what they need. The organisation takes responsibility for confirming whether it is new.Semua ini tidak menuntut teknisi menjadi ahli data. Yang berubah adalah lokasi pengecekannya: dari layar pencarian satu orang ke langkah yang tertata di antara request dan ERP. Requester tetap menjelaskan kebutuhannya, sementara organisasi yang memastikan apakah barang itu memang baru.
The duplicate is decided at registration. The warehouse only stores the result.Kode dobel diputuskan saat registrasi. Gudang hanya menyimpan hasilnya.
The operating model: one governed entry pointModel operasional: satu pintu masuk yang tertata
The operating model is simple to describe. Every request to Create, Change or Delete a material goes through one governed entry point, instead of reaching the ERP by different routes such as email, spreadsheets, direct entry by key users or tickets to IT. The ERP remains the system of record. The entry point becomes the place where requests are screened, routed and approved before anything is written to it.Model operasionalnya sederhana. Setiap request untuk Create, Change, atau Delete material masuk lewat satu pintu yang tertata, bukan lewat banyak jalur seperti email, spreadsheet, input langsung oleh key user, atau tiket ke IT. ERP tetap menjadi system of record. Pintu masuk inilah tempat request disaring, diarahkan, dan disetujui sebelum ada data yang ditulis ke ERP.
Change and Delete deserve the same discipline as Create. A change to a part number or a key attribute can quietly turn a correct record into a misleading one. A deletion or block can leave reservations or work orders pointing at a code that no longer behaves as people expect. Bringing all three through one door keeps the rules, and the record, consistent.Change dan Delete perlu disiplin yang sama dengan Create. Perubahan part number atau atribut kunci bisa diam-diam mengubah record yang benar menjadi menyesatkan. Penghapusan atau block bisa membuat reservasi atau work order mengarah ke kode yang tidak lagi berfungsi seperti yang diharapkan. Dengan menyatukan ketiganya dalam satu pintu, aturan dan catatannya tetap konsisten.
From request to ERP: one entry point, one screen, four approversDari request ke ERP: satu pintu, satu penyaringan, empat pemberi approval
- Request raised A requester submits a Create, Change or Delete request with the details they have.Request diajukan Requester mengajukan request Create, Change, atau Delete dengan detail yang ia punya.
- Single entry point All requests arrive in one governed queue, not via email, spreadsheets or direct ERP entry.Satu pintu masuk Semua request masuk ke satu antrean yang tertata, bukan lewat email, spreadsheet, atau input langsung ke ERP.
- Screening The request is checked against existing part numbers and attributes before any code is issued.Penyaringan Request dicek terhadap part number dan atribut yang sudah ada sebelum kode apa pun diterbitkan.
- Role-based approval The relevant functions review the request and record their decision.Approval berbasis peran Fungsi terkait me-review request dan mencatat keputusannya.
WarehouseGudangProcurementProcurementMaintenanceMaintenanceITIT
- ERP update and audit trail The approved code or change is applied in the ERP, with every decision kept on record.Update ERP dan audit trail Kode atau perubahan yang disetujui diterapkan di ERP, dan setiap keputusan tetap tercatat.
Conceptual illustration, not based on measured data. Routing and sequence can differ by request type and organisation.Ilustrasi konseptual, bukan hasil pengukuran. Alur dan urutan approval bisa berbeda menurut jenis request dan organisasi.
The three request types carry different risks, so it helps to be explicit about what reviewers need to confirm for each one.Ketiga jenis request membawa risiko yang berbeda, jadi sebaiknya jelas apa yang perlu dipastikan reviewer untuk masing-masing.
| Request typeJenis request | Risk without a gateRisiko tanpa gerbang | What reviewers need to confirmYang perlu dipastikan reviewer |
|---|---|---|
| CreateCreate | A second code for a part that already existsKode kedua untuk part yang sebenarnya sudah ada | The part is not already held under another codePart tersebut belum tercatat dengan kode lain |
| ChangeChange | A key attribute altered without the code's users knowingAtribut kunci berubah tanpa diketahui pengguna kode itu | The change is correct and affected functions are awarePerubahannya benar dan fungsi terkait sudah tahu |
| DeleteDelete | A code removed or blocked while stock or open demand still refers to itKode dihapus atau di-block padahal masih ada stok atau kebutuhan terbuka | Nothing is left pointing at the codeTidak ada lagi yang masih mengacu ke kode itu |
How the gate works, brieflyCara kerja gerbangnya, secara singkat
The gate does not need to be complicated to be useful. Before a code is issued, each request is screened against what is already in the master: the manufacturer part number, and the attributes that describe the item, such as type, size, material or rating.Gerbangnya tidak perlu rumit untuk bisa berguna. Sebelum kode terbit, setiap request disaring terhadap isi master data yang sudah ada: part number manufacturer dan atribut yang mendeskripsikan item, misalnya jenis, ukuran, material, atau rating.
Screening on both matters. A part number is often the strongest signal, but it is not always captured, and it may be stored in different formats. Attributes help surface matches that a description alone could miss, for example when the same bearing is recorded once as BRG, BALL 6205 2RS and once in free text by a different team.Keduanya perlu dicek. Part number sering jadi petunjuk paling kuat, tapi tidak selalu diisi dan formatnya bisa berbeda-beda. Atribut membantu memunculkan kecocokan yang bisa terlewat jika hanya mengandalkan deskripsi, misalnya ketika bearing yang sama tercatat sebagai BRG, BALL 6205 2RS di satu record dan sebagai teks bebas oleh tim lain.
When a likely match is foundJika ada kemungkinan kecocokan
The request is held, and reviewers see the existing record alongside the new one.Request ditahan, dan reviewer melihat record lama berdampingan dengan request baru.
- Requester can be pointed to the existing codeRequester bisa diarahkan ke kode yang sudah ada
- Helps avoid a second code and second POMembantu mencegah kode kedua dan PO kedua
- Decision and reason are recordedKeputusan dan alasannya tercatat
When no match is foundJika tidak ada kecocokan
The request moves on to the approving functions with its screening result attached.Request lanjut ke fungsi pemberi approval, lengkap dengan hasil penyaringannya.
- Approvers see what was checkedApprover bisa melihat apa saja yang sudah dicek
- Description and attributes are reviewedDeskripsi dan atribut di-review
- Code is issued only after approvalKode baru terbit setelah disetujui
The point is not that screening will catch every possible duplicate. It is that every request is checked in the same way, at the same place, before it becomes a code, rather than depending on how well one person searched on one busy morning.Intinya bukan bahwa penyaringan akan menangkap semua kemungkinan kode dobel. Intinya, setiap request dicek dengan cara yang sama, di tempat yang sama, sebelum menjadi kode, alih-alih bergantung pada seberapa teliti satu orang mencari di satu pagi yang sibuk.
Who approves: four functions, one recordSiapa yang menyetujui: empat fungsi, satu catatan
Screening answers the question "does this already exist?". Approval answers a different one: "should this exist, and is it described correctly?". That is a judgement no single function can make well on its own, which is why a role-based workflow tends to work better than a single gatekeeper.Penyaringan menjawab pertanyaan "apakah barang ini sudah ada?". Approval menjawab pertanyaan lain: "apakah item ini memang perlu ada, dan apakah deskripsinya sudah benar?". Penilaian seperti itu sulit dilakukan dengan baik oleh satu fungsi saja, sehingga workflow berbasis peran cenderung lebih efektif daripada satu penjaga gerbang tunggal.
| FunctionFungsi | What it typically confirmsYang biasanya dipastikan |
|---|---|
| WarehouseGudang | Whether the part is already held, and how it will be stored and identified on the shelfApakah part sudah ada di stok, serta bagaimana penyimpanan dan identifikasinya di rak |
| ProcurementProcurement | Whether the part can be sourced as described, and whether it overlaps with items already being purchasedApakah part bisa dibeli sesuai deskripsi, dan apakah tumpang tindih dengan item yang sudah rutin dibeli |
| MaintenanceMaintenance | Whether the part is technically right for the equipment, and how critical it isApakah part secara teknis sesuai untuk peralatannya, dan seberapa kritis perannya |
| ITIT | Whether the record meets system and data standards before it is written to the ERPApakah record sudah memenuhi standar sistem dan data sebelum ditulis ke ERP |
Typical responsibilities. Exact roles and sequence depend on your organisation's policy.Tanggung jawab yang umum. Peran dan urutan pastinya bergantung pada kebijakan organisasi Anda.
Every decision along the way is recorded in an audit trail: who requested, what the screening showed, who approved or rejected, and when. That record has practical value. When someone later asks why two similar codes exist, or why a request was turned down, the answer sits in the history rather than in someone's memory or inbox.Setiap keputusan di sepanjang alur tercatat dalam audit trail: siapa yang mengajukan, apa hasil penyaringannya, siapa yang menyetujui atau menolak, dan kapan. Catatan ini punya nilai praktis. Ketika suatu hari ada yang bertanya kenapa ada dua kode yang mirip, atau kenapa sebuah request ditolak, jawabannya ada di riwayat, bukan di ingatan seseorang atau di kotak masuk email.
It also gives leaders something they rarely have today: visibility of how items enter the master. How many requests arrive, how many were matched to existing codes, and where approvals tend to wait all become questions you can answer once requests flow through one door. That is the difference between hoping the item master stays clean and being able to see whether it does.Catatan ini juga memberi pimpinan sesuatu yang jarang mereka punya: visibilitas tentang bagaimana item masuk ke master data. Berapa banyak request yang masuk, berapa yang ternyata cocok dengan kode lama, dan di mana approval sering tertahan, semuanya bisa dijawab begitu request mengalir lewat satu pintu. Bedanya jelas: dari sekadar berharap item master tetap rapi, menjadi bisa melihat apakah memang rapi.
How would a governed flow fit your ERP?Bagaimana alur yang tertata ini cocok dengan ERP Anda?
We can walk through Create, Change and Delete requests using your own roles.Kita bisa telusuri request Create, Change, dan Delete dengan peran di tim Anda sendiri.
A note on the name ANSICatatan soal nama ANSI
In this article, ANSI refers to SCS®-ANSI Module, Panemu's master data governance application. It is not the American National Standards Institute, and it is not related to ANSI standards for parts or materials.Dalam artikel ini, ANSI merujuk pada SCS®-ANSI Module, aplikasi tata kelola master data dari Panemu. ANSI di sini bukan American National Standards Institute, dan tidak berkaitan dengan standar ANSI untuk part atau material.
ANSI is designed to help organisations run the governed entry point described above: one place for Create, Change and Delete requests, screening against existing part numbers and attributes before a code is issued, and a role-based approval workflow across Warehouse, Procurement, Maintenance and IT, with each decision kept in an audit trail.ANSI dirancang untuk membantu organisasi menjalankan pintu masuk tertata seperti yang dijelaskan di atas: satu tempat untuk request Create, Change, dan Delete, penyaringan terhadap part number dan atribut yang sudah ada sebelum kode terbit, serta workflow approval berbasis peran yang melibatkan Gudang, Procurement, Maintenance, dan IT, dengan setiap keputusan tersimpan di audit trail.
Where to start: five questions for leadershipMulai dari mana: lima pertanyaan untuk pimpinan
Before choosing tools, it helps to agree on the decision itself. These questions can frame a first conversation between Operations, Supply Chain, Maintenance and IT.Sebelum memilih tools, ada baiknya sepakat dulu soal keputusannya. Pertanyaan berikut bisa jadi bahan diskusi awal antara Operasional, Supply Chain, Maintenance, dan IT.
- Map the routes. How many ways can a new item reach your ERP today? Count email, spreadsheets, key-user entry and IT tickets.Petakan jalurnya. Ada berapa cara item baru bisa masuk ke ERP Anda saat ini? Hitung email, spreadsheet, input oleh key user, dan tiket ke IT.
- Name the owner. Which function is accountable for the rules of item creation, as distinct from the people who key it in?Tunjuk pemiliknya. Fungsi mana yang bertanggung jawab atas aturan pembuatan item, terpisah dari orang yang menginputnya?
- Define the gate. What must be checked before a code is issued, and what happens when a likely match turns up?Tentukan gerbangnya. Apa yang wajib dicek sebelum kode terbit, dan apa yang terjadi jika muncul kemungkinan kecocokan?
- Agree the approvers. Which functions sign off on Create, Change and Delete, and in what order?Sepakati approver-nya. Fungsi mana yang memberi approval untuk Create, Change, dan Delete, dan bagaimana urutannya?
- Decide what to record. What will you need to see in six months, when someone asks why a code exists?Putuskan apa yang dicatat. Informasi apa yang Anda butuhkan enam bulan lagi, saat ada yang bertanya kenapa sebuah kode ada?
Treat these as a starting point for discussion rather than a diagnosis. The right answers depend on your plant structure, your ERP set-up and how centralised your master data team is. A multi-site operation may need local approvers with a central owner. A single plant may combine roles. What matters is that the answers are written down and that every request follows them.Anggap pertanyaan ini sebagai titik awal diskusi, bukan diagnosis. Jawaban yang tepat bergantung pada struktur plant, konfigurasi ERP, dan seberapa terpusat tim master data Anda. Operasi multi-site mungkin butuh approver lokal dengan satu pemilik pusat, sementara satu plant bisa saja menggabungkan beberapa peran. Yang penting, jawabannya tertulis dan setiap request mengikutinya.
Ready to give item creation a clear owner?Siap memberi pemilik yang jelas untuk pembuatan item?
Talk to us about one governed entry point for your material master.Diskusikan satu pintu masuk yang tertata untuk Material Master Data Anda.
Key TakeawaysPoin Penting
- Many duplicate spare parts begin at registration, when a request reaches the ERP without being checked against what already exists.Banyak spare part dobel bermula saat registrasi, ketika request masuk ke ERP tanpa dicek terhadap data yang sudah ada.
- A "no results" search often means "no match for these words", not "this part does not exist".Hasil pencarian "tidak ditemukan" sering berarti "tidak cocok dengan kata kunci ini", bukan "part ini belum ada".
- The duplicate tends to become visible only after it has a code and a purchase order, which is why it needs leadership ownership.Kode dobel cenderung baru terlihat setelah punya kode dan PO, karena itu perlu pemilik di level pimpinan.
- Treat item creation as a decision with an owner, a gate and a record.Perlakukan pembuatan item sebagai keputusan yang punya pemilik, gerbang, dan catatan.
- Route Create, Change and Delete through one governed entry point, screen against part numbers and attributes, and approve through Warehouse, Procurement, Maintenance and IT with an audit trail.Arahkan Create, Change, dan Delete lewat satu pintu masuk yang tertata, saring terhadap part number dan atribut, lalu proses approval lewat Gudang, Procurement, Maintenance, dan IT dengan audit trail.