Lima Pertanyaan untuk Menguji Apakah Stock Item Siap Diaudit

Why a complete-looking record can still fail an auditMengapa record yang tampak lengkap tetap bisa gagal saat audit

Most data quality checks in an ERP focus on content. Is the description filled in? Is the unit of measure right? Is there a valid material group? Those checks test the result. An audit asks for something different: provenance, meaning the chain of requests and decisions that led to the record existing at all.Sebagian besar pengecekan kualitas data di ERP berfokus pada isi. Apakah deskripsinya terisi? Apakah satuannya benar? Apakah material group-nya valid? Pengecekan seperti itu menguji hasil akhir. Audit menanyakan hal lain, yaitu asal-usul: rangkaian request dan keputusan yang membuat record itu ada sejak awal.

Provenance matters because a material record is more than data. Once a stock item exists, buyers can raise purchase orders against it, planners can set reorder points on it, and the warehouse can hold inventory value under it. If nobody can show why the item was created and who agreed to it, it becomes hard to show that the spending attached to it was controlled.Asal-usul penting karena material record bukan sekadar data. Begitu sebuah stock item ada, buyer bisa membuat purchase order atas item itu, planner bisa memasang reorder point, dan gudang bisa menyimpan nilai inventory di bawah kode tersebut. Kalau tidak ada yang bisa menunjukkan mengapa item itu dibuat dan siapa yang menyetujuinya, sulit pula membuktikan bahwa pengeluaran yang melekat padanya sudah terkendali.

Consider the record below. Every field that describes the valve is populated. Almost every field that would explain the valve's history is blank or filled by a system account.Coba lihat record berikut. Semua kolom yang menjelaskan valve-nya terisi. Sebaliknya, hampir semua kolom yang bisa menjelaskan riwayat valve itu kosong atau diisi akun sistem.

The five numbered tags map to the five questions in this checklist. Each one can be asked about a single record, which keeps the test quick to run and hard to argue with.Kelima tag bernomor itu sama dengan lima pertanyaan dalam checklist ini. Setiap pertanyaan bisa diajukan untuk satu record saja, sehingga pengujiannya cepat dilakukan dan sulit dibantah.

How to use the checklistCara memakai checklist ini

Pick one record, ideally one created or changed in the last twelve months, and ask each question in turn. Accept evidence, not recollection. "I think Budi requested it" is a memory. A request form showing Budi's name, his department, the date and the reason is evidence.Ambil satu record, sebaiknya yang dibuat atau diubah dalam dua belas bulan terakhir, lalu ajukan pertanyaannya satu per satu. Terima bukti, bukan ingatan. "Kayaknya Pak Budi yang minta" itu ingatan. Form request yang mencantumkan nama Pak Budi, departemennya, tanggal, dan alasannya, itu baru bukti.

Score each question as answered, partly answered or not answered. A pattern across ten or twenty records usually tells you more than any single result, because it shows whether a gap is an exception or the way the process actually works.Beri nilai tiap pertanyaan: terjawab, terjawab sebagian, atau tidak terjawab. Pola dari sepuluh atau dua puluh record biasanya lebih bermakna daripada satu hasil tunggal, karena dari situ terlihat apakah celahnya hanya pengecualian atau memang begitulah proses berjalan sehari-hari.

Question 1: Who requested it?Pertanyaan 1: Siapa yang meminta item ini?

The first question is the simplest, and often the first to fail. The answer should be a named person with a role and a department or plant. A system account, a shared login or a team name does not count.Pertanyaan pertama ini paling sederhana, dan sering kali justru yang pertama gagal. Jawabannya harus nama orang, lengkap dengan peran dan departemen atau plant-nya. Akun sistem, login bersama, atau nama tim tidak dihitung.

Generic creators appear for understandable reasons. Data migrated at go-live is usually loaded by a batch user. In many organisations a central master data team keys in every new item from emails or spreadsheets, so the ERP shows the cataloguer as the creator rather than the person who needed the part. In both cases the ERP records who typed, not who asked.Nama pembuat yang generik muncul karena alasan yang wajar. Data yang dimigrasi saat go-live biasanya dimuat oleh user batch. Di banyak perusahaan, tim master data pusat menginput setiap item baru berdasarkan email atau spreadsheet, sehingga ERP mencatat cataloguer sebagai pembuat, bukan orang yang sebenarnya butuh part itu. Dalam dua kasus tersebut, ERP mencatat siapa yang mengetik, bukan siapa yang meminta.

Why it matters: the requester is the person who can explain the business need. If the valve was requested for a specific pump overhaul, that link explains why the item exists and whether it is still needed today. Without it, the record cannot be tied back to a real operational demand.Kenapa ini penting: requester adalah orang yang bisa menjelaskan kebutuhan bisnisnya. Kalau valve tadi diminta untuk overhaul pompa tertentu, kaitan itu menjelaskan alasan item tersebut ada dan apakah masih dibutuhkan sekarang. Tanpa kaitan itu, record tidak bisa ditelusuri kembali ke kebutuhan operasional yang nyata.

Question 2: Was it checked against existing stock, and is there evidence?Pertanyaan 2: Apakah sudah dicek terhadap stok yang ada, dan mana buktinya?

Duplicate materials are one of the most familiar master data problems. The same valve might already exist under another code as VALVE, BALL 2IN rather than BALL VALVE 2 SS316 FLGD. An auditor will want to know whether anyone looked before the new code was created.Material dobel termasuk masalah master data yang paling sering ditemui. Valve yang sama bisa saja sudah ada dengan kode lain, tertulis VALVE, BALL 2IN dan bukan BALL VALVE 2 SS316 FLGD. Auditor akan bertanya apakah ada yang mengecek dulu sebelum kode baru dibuat.

Most teams will say yes. The harder part is proving it. A search someone ran on their own screen two years ago leaves no trace unless the process records it somewhere.Hampir semua tim akan menjawab sudah. Bagian yang lebih sulit adalah membuktikannya. Pencarian yang dilakukan seseorang di layarnya dua tahun lalu tidak meninggalkan jejak, kecuali prosesnya memang mencatat hasil pencarian itu.

Why it matters: an unchecked new code can split stock, purchase history and demand across two records. That can lead to buying an item that is already sitting on a shelf, and it weakens any spend analysis that depends on one item having one code.Kenapa ini penting: kode baru yang tidak dicek bisa memecah stok, riwayat pembelian, dan kebutuhan ke dua record berbeda. Akibatnya, perusahaan bisa membeli item yang sebenarnya sudah ada di rak, dan analisis spend yang mengandalkan prinsip satu item satu kode jadi kurang bisa dipegang.

Question 3: Which cataloguing standard was the description written to?Pertanyaan 3: Deskripsinya ditulis mengikuti standar cataloguing yang mana?

A description can look tidy and still follow no rule. BALL VALVE 2 SS316 FLGD is readable, but the auditor's question is whether it was written to a defined naming convention and attribute template, and which version of that standard applied at the time.Deskripsi bisa terlihat rapi tetapi sebenarnya tidak mengikuti aturan apa pun. BALL VALVE 2 SS316 FLGD memang mudah dibaca, tetapi auditor ingin tahu apakah deskripsi itu ditulis berdasarkan naming convention dan template atribut yang jelas, dan versi standar mana yang berlaku saat itu.

Cataloguing standards vary. Many organisations use a noun-modifier naming convention with an attribute template per item class, and some also map items to a classification scheme such as UNSPSC or eCl@ss. For this test, the specific choice matters less than three facts: a standard exists, it is documented, and it was applied to this record.Standar cataloguing di tiap perusahaan bisa berbeda. Banyak yang memakai naming convention noun-modifier dengan template atribut per kelas item, dan sebagian juga memetakan item ke skema klasifikasi seperti UNSPSC atau eCl@ss. Untuk pengujian ini, pilihan standarnya tidak terlalu menentukan. Yang penting ada tiga hal: standarnya ada, terdokumentasi, dan benar-benar diterapkan pada record ini.

Why it matters: a standard is what makes descriptions comparable. If two cataloguers can describe the same valve in two different ways, duplicate checks become less reliable, and question 2 becomes harder to answer for every item that follows.Kenapa ini penting: standar itulah yang membuat deskripsi bisa dibandingkan satu sama lain. Kalau dua cataloguer bisa menulis valve yang sama dengan dua cara berbeda, pengecekan duplikat jadi kurang andal, dan pertanyaan 2 makin sulit dijawab untuk item-item berikutnya.

Question 4: Who approved it, and when?Pertanyaan 4: Siapa yang menyetujuinya, dan kapan?

Approval is where many records fall silent. The ERP may have no approval step for material creation at all, or approval may have happened in an email thread, a chat message or a quick conversation in the corridor. None of these is attached to the record.Di bagian approval inilah banyak record tidak bisa bicara. Bisa jadi ERP sama sekali tidak punya langkah approval untuk pembuatan material, atau approval-nya terjadi lewat thread email, pesan chat, atau obrolan singkat di lorong kantor. Semua itu tidak menempel pada record.

The "when" matters as much as the "who". An approval dated after the record was created is a retrospective sign-off, not a control. Auditors also look at segregation of duties: if the same person requested, approved and created the item, the approval adds little assurance.Soal "kapan" sama pentingnya dengan "siapa". Approval yang tanggalnya setelah record dibuat hanyalah pengesahan susulan, bukan kontrol. Auditor juga akan melihat pemisahan tugas (segregation of duties): kalau orang yang sama yang meminta, menyetujui, sekaligus membuat item, approval tersebut nyaris tidak memberi jaminan apa pun.

Why it matters: approval is the control that decides whether an item should enter the system at all. Without evidence of it, every purchase raised against that code rests on a decision nobody can verify.Kenapa ini penting: approval adalah kontrol yang menentukan apakah sebuah item layak masuk ke sistem atau tidak. Tanpa bukti approval, setiap pembelian atas kode itu berdiri di atas keputusan yang tidak bisa diverifikasi siapa pun.

Question 5: What changed since creation, and why?Pertanyaan 5: Apa yang berubah sejak dibuat, dan kenapa?

Records rarely stay as they were created. Descriptions get corrected, units change, items are flagged for deletion or brought back into use. Many ERPs can log field-level changes, showing the old value, the new value, the user and the time. What that log tends to miss is the reason.Record jarang sekali bertahan persis seperti saat pertama dibuat. Deskripsi dikoreksi, satuan diganti, item ditandai untuk dihapus lalu dipakai lagi. Banyak ERP bisa mencatat perubahan per kolom, lengkap dengan nilai lama, nilai baru, user, dan waktunya. Yang biasanya tidak tercatat adalah alasannya.

An auditor looking at a valve whose unit of measure moved from EA to SET, or whose material group was switched, will ask why. "Someone fixed it" does not hold up, especially when the change affects how stock is counted or valued.Auditor yang melihat valve dengan satuan berubah dari EA menjadi SET, atau material group-nya dipindah, tentu akan menanyakan alasannya. Jawaban "ada yang membetulkan" tidak cukup, terlebih kalau perubahan itu memengaruhi cara stok dihitung atau dinilai.

Why it matters: unexplained changes can affect valuation, reorder settings and reporting. A change to a stocked item deserves the same discipline as its creation, because in practice it can have just as much impact.Kenapa ini penting: perubahan tanpa penjelasan bisa berdampak pada valuasi, setting reorder, dan pelaporan. Perubahan pada item yang distok layak mendapat disiplin yang sama dengan pembuatannya, karena di lapangan dampaknya bisa sama besar.

The five questions at a glanceLima pertanyaan dalam satu tabel

The table below puts the five questions side by side. It can be printed and used as a working sheet when testing a sample of records.Tabel berikut merangkum kelima pertanyaan dalam satu tampilan. Tabel ini bisa dicetak dan dipakai sebagai lembar kerja saat menguji sampel record.

Why provenance is hard to rebuild laterKenapa asal-usul data sulit disusun ulang belakangan

Each of the five answers is cheapest to capture at the moment the record is created. At that moment the requester is known, the search has just been run, the approver is reachable and the reason is fresh in everyone's mind.Kelima jawaban tadi paling murah dicatat tepat saat record dibuat. Pada saat itu requester-nya jelas, pencarian baru saja dilakukan, approver mudah dihubungi, dan alasannya masih segar di kepala semua orang.

A year later, the picture looks different. People change roles or leave, inboxes are archived, and the spreadsheet that held the original request may sit on a shared drive nobody can find. Teams then try to reconstruct evidence after the fact. That takes time, and it may still not satisfy an auditor, because evidence assembled after the event is weaker than evidence created during it.Setahun kemudian, ceritanya lain. Orang pindah posisi atau resign, inbox sudah diarsipkan, dan spreadsheet berisi request awal mungkin tersimpan di shared drive yang tidak ada lagi yang tahu letaknya. Tim akhirnya mencoba menyusun ulang bukti setelah kejadian. Prosesnya makan waktu, dan hasilnya belum tentu diterima auditor, karena bukti yang dikumpulkan belakangan lebih lemah daripada bukti yang tercipta saat kejadian berlangsung.

This is why the test is less about the ERP itself and more about what happens before data reaches it. If the request process does not capture who, what, when, why and who approved, the ERP has nothing to show when the auditor asks.Karena itulah pengujian ini sebenarnya tidak terlalu soal ERP-nya, melainkan soal apa yang terjadi sebelum data masuk ke ERP. Kalau proses request tidak mencatat siapa, apa, kapan, kenapa, dan siapa yang menyetujui, ERP tidak punya apa-apa untuk ditunjukkan saat auditor bertanya.

How a governed request flow captures the answers at entry timeBagaimana alur request yang terkelola mencatat jawabannya sejak awal

A governed request flow moves the five questions to the front of the process. Instead of asking them during an audit, the process asks them before a record is written to the ERP, and keeps the answers with the request so they can be retrieved later.Alur request yang terkelola memindahkan kelima pertanyaan itu ke awal proses. Pertanyaannya tidak lagi muncul saat audit, tetapi diajukan sebelum record ditulis ke ERP, dan jawabannya disimpan bersama request sehingga bisa ditarik kembali kapan pun dibutuhkan.

This is the model behind ANSI, Panemu's web-based Master Data Governance application (the name has no connection to the American National Standards Institute). ANSI is designed to sit in front of an ERP/EAM. Create, Change and Delete requests for material master records pass through duplicate screening against the ERP master, validation against business rules, and a role-based approval workflow before they reach the system of record. Approved requests are then catalogued with SCS^® (Spares Cataloguing System^®).Model inilah yang menjadi dasar ANSI, aplikasi Master Data Governance berbasis web dari Panemu (namanya tidak berkaitan dengan American National Standards Institute). ANSI dirancang untuk berada di depan ERP/EAM. Request Create, Change, dan Delete untuk material master record melewati screening duplikat terhadap master ERP, validasi terhadap business rules, dan approval workflow berbasis role sebelum sampai ke system of record. Request yang disetujui kemudian dikatalogkan dengan SCS^® (Spares Cataloguing System^®).

For audit purposes, the useful part is the trail ANSI keeps for each request: who submitted it, what was requested, when it was submitted and approved, the business reason, and who reviewed and approved it. Those five points line up closely with the five questions in this checklist. ANSI does not replace the ERP, and it does not on its own make historical records audit-ready; items created before a governed flow was in place may still need a separate review.Untuk kepentingan audit, bagian yang paling berguna adalah jejak yang disimpan ANSI untuk setiap request: siapa yang mengajukan, apa yang diajukan, kapan diajukan dan disetujui, alasan bisnisnya, serta siapa yang mereview dan menyetujuinya. Kelima poin itu sejalan dengan lima pertanyaan dalam checklist ini. ANSI tidak menggantikan ERP, dan tidak serta-merta membuat record lama siap diaudit; item yang dibuat sebelum alur terkelola berjalan mungkin tetap perlu direview tersendiri.

Run the test before the auditor doesJalankan tesnya sebelum auditor datang

Teams that expect an audit do not need to wait for the first question. The same checklist works as a self-assessment, and running it early turns an uncomfortable meeting into a planned piece of work.Tim yang tahu akan diaudit tidak perlu menunggu pertanyaan pertama dilontarkan. Checklist yang sama bisa dipakai untuk self-assessment, dan menjalankannya lebih awal mengubah rapat yang canggung menjadi pekerjaan yang terencana.

1. Take a sample. Pull ten to twenty stock items created or changed in the past year, plus a few critical or high-value spares.Ambil sampel. Tarik sepuluh sampai dua puluh stock item yang dibuat atau diubah setahun terakhir, ditambah beberapa spare part kritis atau bernilai tinggi.
2. Ask all five questions per record. Note what evidence exists, where it sits and how long it took to find.Ajukan kelima pertanyaan untuk tiap record. Catat bukti apa yang ada, di mana letaknya, dan berapa lama waktu untuk menemukannya.
3. Sort the gaps by cause. A missing process (no approval step exists), missing capture (the step exists but leaves no record), or a missing link (evidence exists but is not tied to the record).Kelompokkan celah berdasarkan penyebabnya. Prosesnya tidak ada (tidak ada langkah approval), pencatatannya tidak ada (langkahnya ada tetapi tidak meninggalkan jejak), atau kaitannya tidak ada (buktinya ada tetapi tidak terhubung ke record).
4. Fix the flow before the backlog. Closing the gap for new requests stops the problem growing. Legacy records can then be reviewed by risk, starting with critical and high-value items.Benahi alurnya dulu, baru backlog-nya. Menutup celah untuk request baru mencegah masalahnya bertambah. Setelah itu, record lama bisa direview berdasarkan risiko, dimulai dari item kritis dan bernilai tinggi.
5. Agree on the evidence standard. Settle with Internal Audit what "audit-ready" means for your organisation, so both sides test against the same bar.Sepakati standar buktinya. Tentukan bersama Internal Audit apa arti "siap diaudit" di perusahaan Anda, supaya kedua pihak menguji dengan ukuran yang sama.

Key TakeawaysPoin Penting