Manufacturing vs internet company: where DCMM actually differs

Two types of company side by side: one table to see where the paths split

Start with the whole picture. The way to use this table is not to memorise it, but to hold it against your own company: whichever column describes you more closely is where the preparation weight belongs. In reality plenty of companies are hybrids — a manufacturing company with its own software team and an industrial internet platform, an internet company that also makes smart hardware and runs its own supply chain. A hybrid has to judge row by row rather than copy a whole column: whichever part of the business is making things is prepared along the manufacturing column, and whichever part is operating users online is prepared along the internet column.

1. Data sources and collection: equipment and process, or tracking and logs

This is where the two paths fork, and the source of everything downstream. The Level 3 playbook, domain by domain, made one point: each of the eight capability domains has to produce the trio of policy + execution + result. And the starting point of that trio is always “where the data comes from”. If the collection layer is not sorted out, the standards, quality and security that follow are built on nothing.

Manufacturing: three kinds of source, three levels of trust

A manufacturing company's data sources split into three blocks, and their credibility and governance difficulty are not the same:

• Equipment data: PLCs, SCADA, CNC machines, robots, injection moulding machines, inspection equipment, energy meters. High frequency, narrow fields, long time series, and a wide spread of protocols (OPC UA, Modbus, and every vendor's own), so collection usually goes through an edge gateway. This data is “large in volume but not necessarily useful” — several hundred points may be collected, and only a dozen of them actually feed quality judgement and process optimisation.
• Business document data: orders, purchasing, inventory and cost in ERP; work orders, reporting, material issue and batches in MES; drawings, BOM and change orders in PLM; inspection and nonconforming product in QMS; inbound and outbound movement in WMS. This block decides whether the books reconcile with the physical goods, and whether the traceability chain can run through.
• Manual data: team leaders reporting completion, inspectors filling in inspection records, warehouse staff counting material, shift handover books, paper routing sheets, rework and repair records. This block is large, its conventions are loose, and it is where on-site questions tend to find trouble, because it decides whether “the number in the system” and “the fact on the shop floor” are the same thing.

Four things a manufacturing company specifically has to do: first, build a data source list — for every source, write down which system or which machine it is, what data it produces, who collects or enters it, at what frequency, into which table it lands, and which post owns it. Second, fix a time baseline — equipment clocks, shift start and end, work order open and close times must line up, or yield and takt analysis is misaligned from the start. Third, fix the back-fill rule — when the network drops, a machine fails or a system goes down, who enters the data by hand, within how long, and whether back-filled data is flagged; without that rule written down, the quality domain can never explain “what this gap is”. Fourth, collect narrow before wide — start with the key parameters of three to five critical operations and get the chain working, which is far more practical than instrumenting the whole plant at once.

Internet: tracking is part of the product

An internet company's data is nearly all generated automatically, but “automatic” does not mean “reliable”. The main sources are client and server-side tracking, gateway and service logs, business databases (orders, payments, accounts), third-party callbacks (channels, campaigns, app stores, support tickets) and experiment assignment records. The real difficulty is not whether the data can be collected, but that the tracking code is itself part of the product code, and it changes with every release: this version adds a parameter, the next changes when the event fires, the one after takes the event offline, and the dashboard is still running on the old logic.

Four things an internet company specifically has to do: first, a tracking specification — how events are named, how parameters are defined, when they fire, which fields are mandatory, written so a developer can work straight from it rather than from a slide deck. Second, a tracking change process — adding, changing or retiring an event goes through one confirmation: who raised it, which downstream reports and metrics it affects, who was notified, when it takes effect. Third, monitoring of collection quality — a sudden drop in reporting volume, one client version under-reporting, fields largely empty: these have to be found automatically, not left until a business team says “this number looks wrong”. Fourth, rules for stitching user identifiers together — device identifiers, account identifiers, and the merge rule from anonymous to logged-in; only once that is written down does “how many users does this count as” have an answer.

2. Data architecture: master data and system boundaries, or warehouse layers and real-time pipelines

Data architecture is the domain that tends to look present while being absent. A manufacturing company often presents a system integration topology as its architecture; an internet company often presents a warehouse layer diagram. Both draw only half of it.

Manufacturing: the difficulty is heterogeneity and boundaries

A manufacturing company's system landscape usually looks like this: ERP handles orders, purchasing, inventory and cost; MES handles work orders, reporting, material issue and traceability; PLM handles drawings, BOM and changes; WMS handles locations and movement; QMS handles inspection and nonconforming product; SCADA and the device layer handle real-time parameters. These systems were often delivered by different vendors in different years, with interfaces that in some places are standard APIs, in others intermediate tables, in others scheduled file imports, and in a few places a person importing Excel by hand. What the architecture domain really has to answer is three things: which system is the source, how the data is synchronised, and who owns it when synchronisation fails.

What a manufacturing company specifically has to do: first, name the source system — is material master data in ERP or PLM, is the valid BOM version in PLM or MES, are work orders created only in MES, are inspection results created only in QMS. Once the source is confused, every report below it contradicts the others. Second, a mechanism for adding and changing master data — who applies, who approves, how often it synchronises, how a failed synchronisation is repaired, and how old codes map to new ones. Third, draw the data distribution map along the business main line, not by system: material → BOM → work order → batch → inspection → goods receipt → shipment; for each segment, where it lives and by which key it is joined. Fourth, list “manual import” as a pipeline in its own right — it is often the weakest link in the chain, and often the one that gets probed in an interview. Fifth, layer OT and IT — whether edge collection, plant-level aggregation and group-level consolidation each happen at their own layer determines data latency and what is available when the network is down.

Internet: the difficulty is layering and consistency

An internet company's architecture problem is not too many systems but too many pipelines: the same business fact may exist at the same time in the business database, the offline warehouse, the real-time pipeline, the metric platform and several self-service analysis tables. When the layers are unclear, the same GMV appears as five different numbers in five places, and everyone believes their own table is the right one.

What an internet company specifically has to do: first, fix what each layer is for — what belongs in the ingestion layer, the detail layer, the summary layer and the application layer, who may write and who may only read, and no direct cross-layer access. Second, model the core facts and dimensions — how the order, payment, behaviour, user, product and channel tables are built, at what grain, and how degenerate dimensions are handled. Third, monitor consistency across the real-time and offline pipelines — the difference between the two for the same metric needs day-to-day monitoring, and a breach of threshold needs a named person to look, not a business team to notice. Fourth, register and version the data services — interfaces provided to others need a list, an owner, call volumes and a change record. Fifth, collect metadata and lineage automatically — hand-maintained metadata rarely survives three months, which is a common experience; being able to pick a table at random on site and pull out its field meanings and its upstream and downstream is what makes this domain stand up.

3. Data quality: does not reconcile, or does not arrive in time

Quality is easily misunderstood among the eight capability domains. Plenty of companies take it to mean “clean data”, when what is actually assessed is whether problems are found reliably and closed once found. And “what counts as a problem” is not the same thing on the two sides at all.

Manufacturing: book-to-physical consistency and traceable batches

A manufacturing company's quality problems concentrate in four places:

• One item, several codes — and one code, several items: the same specification was created once in each period, by each buyer, at each plant, and four codes now sit in the system; or one code covers two specifications, and both purchasing and material issue go wrong.
• BOM version misalignment: the work order uses the old BOM while material is actually issued against the new one, so cost accounting and traceability both fail to reconcile.
• Book-to-physical mismatch: the difference between system inventory and the physical count stays open for months with nobody to write it off, until “the number in the system is a reference” becomes the working assumption.
• Broken batch genealogy: the links between raw material batch, work-in-process batch and finished batch are recorded only at some operations, and once a step comes back from a subcontractor the chain no longer joins.

What a manufacturing company specifically has to do: first, close the loop on three to five key data items — pick from material, BOM, work order, batch and inventory according to business impact, rather than covering everything at once. Second, the rules have to say what counts as an error — duplicate material codes, a BOM version inconsistent with the work order, a reported quantity deviating from goods receipt beyond a threshold, a missing batch link, a key parameter outside the process window: every rule with a threshold and an owner. Third, the issue log needs four stages to be a loop — found, assigned, corrected, verified; without verification it is only a list. Fourth, run one traceability drill and keep the record: pick a finished goods batch at random, trace forwards to the raw material batches and suppliers and backwards to the customers shipped to, within a time limit, recording how long it took and where it broke. The value of that one drill usually exceeds ten pages of policy.

Internet: timeliness, completeness and stable definitions

An internet company's quality problems concentrate in four other places: timeliness (a report due at eight in the morning finishing at ten), completeness (one client version under-reports and a whole channel reads low), no duplication (one click reported twice, one order counted twice) and consistency (after a definition change the history is not recomputed, and an unexplained step appears on the trend line). On top of these sits a special category: abnormal traffic — fake orders, crawlers, emulators — which drags every downstream metric off course.

What an internet company specifically has to do: first, land the generic rules on core tables — primary keys not duplicated, key fields not null, enumerated values in range, amounts reconcilable against the order table; those four cover a good share of the low-level errors. Second, timeliness needs a commitment and an alert — what time each core table promises to be ready and who is notified when it is late, rather than someone refreshing the page in the morning. Third, a definition change has to register its blast radius — who is notified, whether history is recomputed, how the dashboard is annotated; these three decide whether the downstream redoes everything. Fourth, rules for identifying abnormal traffic — device fingerprints, behavioural sequences, frequency thresholds — and the rules themselves need an owner and a review cycle. Fifth, someone has to read the quality dashboard — how many checks this period, how many issues found, how many closed, discussed at a regular meeting; only then has quality work entered the mechanism.

4. Data standards: codes, or definitions

In this domain the two kinds of company produce completely different artefacts: a manufacturing company's standards are sets of coding rules, an internet company's standards are sheets of metric definitions. What is assessed differs too — the first for “has the code landed in system fields”, the second for “do two departments report the same metric as the same number”.

Manufacturing: turn standards into codes

The standards a manufacturing company sets are basically these: material codes (one item, one code, covering classification, specification, material, unit, drawing number and version), BOM structure standards (levels, substitutes, version effective and expiry rules), operation and work centre codes, equipment codes, supplier and customer codes, inspection items and defect codes, units of measure and conversion rules.

What a manufacturing company specifically has to do: first, take material and supplier as the two master data to start with — the disputes are real, the effect is visible, and business support is easier to obtain. Second, the coding rule has to say what each position means, who applies, who approves and who may change; writing only “codes must not repeat” achieves nothing, and only a written application path has force. Third, clean up historical duplicates but keep the mapping — merging outright leaves historical documents unable to reconcile, so a cross-reference table of old and new is the practical route. Fourth, the standard has to land in system fields: material master fields in ERP, operation codes in MES, defect codes in QMS; only field-level alignment counts as implementation, and a conformance check against the standard before a new system goes live is a record that carries weight in an assessment.

Internet: turn standards into definitions

The standards an internet company sets are another set of objects: the metric dictionary (definition, formula, data range, owning team, version), the dimension system (channel, client, version, region, audience), event naming conventions, user identifiers and de-duplication rules, and code tables (industry, category, content tag).

What an internet company specifically has to do: first, the metric dictionary has to be searchable — anyone searching a metric name should see the definition, the formula, the boundary of the definition and the owner. A dictionary parked on a shared drive that nobody opens is the same as not having one. Second, metrics with the same name but different meanings have to be merged or renamed — words like “active”, “retention” and “valid order” often mean different things in different teams, and until that conflict is resolved, cross-department meetings argue about definitions indefinitely. Third, dimension values have to converge — channel names copied from an ad platform arrive in every shape, and one channel ends up split into seven or eight values by case, space and suffix; this kind of dirty data pollutes all the way to the reports. Fourth, a standard change has to assess its downstream impact — change one metric formula and you need a list of which dashboards, which interfaces and which external reports are affected.

5. Data security: drawings leaving the gate, or data being exported

Data security carries real weight among the eight capability domains, but the objects the two kinds of company protect are in effect two different things. A manufacturing company protects “things” — drawings, recipes, process parameters; an internet company protects “people” — users' identity, behaviour, location and payment information. The data security perspective in DSMM can be borrowed here, but the object has to be swapped.

Manufacturing: classification has to land at file and field level

A manufacturing company's sensitive objects are concrete: product drawings and 3D models, process recipes and key parameters, BOM and cost, technical documents supplied by customers, quotations and tender documents, moulds and machining programs. The exits are equally concrete: subcontractors, mould shops, the remote maintenance channel of equipment vendors, resident engineers, retired equipment and hard disks, and the shared terminal on the shop floor that anyone can use.

What a manufacturing company specifically has to do: first, classification has to land at two levels — the file level (which shared folder, which drawing library belongs to which class) and the system field level (which class the process parameters in MES and the cost fields in ERP belong to). Writing only “public / internal / confidential” without mapping it to concrete objects means this domain has not been done. Second, a post–permission matrix — what R&D, process, production, quality, purchasing and finance may each see and change, confirmed and signed by the business departments, implemented by IT. Third, an outbound register — object, version, purpose, whether returned or destroyed, and the person who handled it; that register proves both that the risk was identified and that the measure is being executed. Fourth, control remote maintenance — request, time limit, someone present, session record; leave out one of the four and it will be probed. Fifth, do not forget availability — data security in manufacturing is not only confidentiality, it also includes “this line cannot stop”; network-down permissions, backup and restore, and the recoverability of machine programs all sit inside this domain's boundary.

Internet: classification has to land on personal information fields

An internet company's sensitive objects are personal information and user data: phone numbers, identity documents, addresses, location trails, device identifiers, payment and billing, communications and content, and the combination of fields that can identify a person indirectly. The exits cluster around: data export, cross-department data pulls, sharing with partners and advertisers, using production data in test environments, permissions for outsourcers and interns, and accounts left behind after someone leaves.

What an internet company specifically has to do: first, a personal information inventory — which table, which field is personal information, how sensitive it is, who uses it and in what scenario. That inventory is the foundation of the security domain and the key to aligning with the data asset catalogue. Second, four steps with a trail for permissions — request, approval, provisioning, periodic review, with sensitive fields authorised separately; provisioning without review is a common gap. Third, put a separate gate on export and outbound sharing — who exported what, to whom, for what purpose needs approval and a record; the chance of this being sampled on site is high. Fourth, mask test data — do not copy the production database straight into a test environment, and the masking rules need to be written down with execution records. Fifth, logs have to be queryable — not “logging is on”, but being able to run a query on site by person, by table and by time period, having actually done so in the past, and having the review record to show.

6. Data application: what changed on the floor, or how far a metric moved

Data application is the domain that looks at results, and the one that is easiest to turn into a project list. What the assessment cares about is not how many reports were built or how many models went live, but whether data actually changed a decision or an action.

Manufacturing: value has to return to parameters, batches and the shop floor

Typical application scenarios in manufacturing are: scheduling and capacity optimisation, yield and defect analysis, predictive maintenance, energy and process window optimisation, quality traceability, supplier performance evaluation, cost and inventory analysis. The common thread is that value is recovered slowly, verification takes time, and the conclusion has to go back to the shop floor — if the analysis says a temperature stage should come down five degrees, process has to confirm it, a trial run has to happen, and several consecutive batches of yield have to be watched before it counts.

What a manufacturing company specifically has to do: first, write the scenario list in four parts — problem, data, action, effect — and the effect needs a baseline (what it was before) and a comparison (what it is after); an effect described without a baseline will not hold up in an interview. Second, pick three to five scenarios whose results you can describe and complete the process records, which is more persuasive than listing twenty scenarios nobody uses. Third, embed the application in existing routines — the MES dashboard, the quality meeting pack, the monthly business review; hung there, someone will see it. Building a separate data platform that nobody logs into is a common waste. Fourth, traceability applications have to be demonstrable on site — click a batch number and the answer appears in seconds; if it cannot be shown, every traceability policy written before it comes under suspicion.

Internet: value has to return to metrics and experiments

Typical scenarios on the internet side are: acquisition and win-back, retention and segmented operations, recommendation and search, risk control and anti-fraud, campaign effectiveness measurement, A/B experiments. The common thread is that the loop closes fast, experiments are possible, and the metric maps directly to revenue or retention — which is also why an internet company's application evidence often looks better presented than a manufacturing company's, while being just as easy to leave empty: many reports, and very few that can say which decision used them.

What an internet company specifically has to do: first, experiments need a register — what the hypothesis was, how traffic was split, which metrics were watched, what the conclusion was, whether it shipped; all five. The experiment register is heavy evidence in this domain. Second, for each scenario write “which data was used, which metric it affected, what the result was”, rather than “we launched a recommendation system”. Third, data services need a catalogue and call records — who can request, how to request, who it was given to, how often it is called; only when those four questions have answers is open sharing actually in place. Fourth, do not watch only the line that went up — experience metrics, complaint rates and refund rates belong on the dashboard too; an analysis that reports only good news does not survive questioning in an interview.

7. Where an assessment interview tends to push

The assessment logic is the same: follow one chain from data source → standard → quality → application and see whether it runs all the way through, then come back and check whether governance, security, architecture and lifecycle are holding it up. But what gets pulled out is completely different between the two kinds of company.

What manufacturing companies get pushed on

• Production, yield and first-pass yield: production, quality and finance each report a different number. Which definition does the difference come from?
• Give me a finished goods batch number, find its raw material batches and suppliers now, then trace it forward to the customers it was shipped to.
• Why does the same specification of material have four codes, which one is right, and how are historical documents handled?
• Who stamps the timestamp on equipment data, how is it aligned with shifts and work orders, and was the gap during the network outage back-filled?
• Are these reports generated by the system, or does someone import Excel every month? Who does it, and how often?
• Who approves the creation and change of material master data, how long until downstream systems synchronise, and has it ever failed?
• When the work order status in MES does not match the paper routing sheet on the floor, which one wins?
• Who chairs the data governance meeting, how often does it meet, what was on the last agenda, and how far did the actions get?

What internet companies get pushed on

• How many times has this metric's definition changed, how was historical data handled each time, and is there a note on the dashboard?
• Has one client version ever under-reported its tracking, who found it, and how was the data back-filled?
• How far apart are the offline and real-time pipelines for the same metric, where is the difference monitored, and who looks when it breaches the threshold?
• Which tables and which fields are personal information, who uses them, has any been exported, and where is the record?
• Where does the test environment's data come from, what are the masking rules, and who executes them?
• Where are the hypothesis, traffic split, metrics and conclusion of the last experiment, and did it ship?
• Who maintains the warehouse layering rules, and does anyone stop a new table being built at the wrong layer?
• Pick a core table on the spot: can you pull out its field meanings, its upstream tables and its owner?

The skeleton both types of company share

Having set out the differences, the shared part has to be stated too — it does not change with industry, and it does not stop working because the industry is different. DCMM's eight capability domains are one set: Data Strategy, Data Governance, Data Architecture, Data Application, Data Security, Data Quality, Data Standards, Data Lifecycle; the five levels are one set of names too: Level 1 Initial, Level 2 Managed, Level 3 Robust, Level 4 Quantitatively Managed, Level 5 Optimizing. The process is the same as well: level and scope → gap analysis → build mechanisms rather than documents → assemble material → document review → on-site assessment → result and improvement. The overall flow and the points where work gets redone are set out in more detail in the full assessment process; the differences between levels are in the five levels, one by one.

These practices can be shared outright by both kinds of company:

• How to write the data strategy: goal → annual actions → owning department → resources → checkpoints. After each goal add one sentence: “what is the concrete action this year”. A goal that cannot be followed by that sentence should be deleted.
• The governance skeleton: a layered governance structure (decision, coordination, execution), three tiers of documents — a master policy, domain-level procedures and operating instructions — accountability assigned to posts and signed, regular meetings with resolutions and tracking, and one or two data indicators brought into departmental appraisal.
• Three things that have to line up: an approval step written in the policy needs a matching node in the system and a matching document in the register. Only when the three are joined is it an evidence chain.
• Continuity in time: meetings, checks, corrective actions and training all need records spanning months, even quarters. If every record falls inside the last two months, the reality of the mechanism is questioned.
• Traceable accountability: every record traces to a specific post and person; “the relevant department” is not an answer. And the person held accountable has to know they are.
• Cross-domain consistency: the security domain's classification has to align with the data asset catalogue, the standards domain's metric definitions with the quality domain's rules, and the governance domain's accountability list with the people who review permissions in the security domain.
• Interview preparation: the governance lead, a contact in each domain, and an executive who can explain the investment — those three have to be genuinely doing the work; a consultant cannot stand in for them.

What cannot be shared is only the professional core: material and BOM, batch genealogy, equipment collection, process windows and the subcontracting information flow on the manufacturing side; the tracking system, metric definitions, real-time pipelines, personal information and experiment mechanism on the internet side. In other words, the skeleton is the same; the objects, scenarios and evidence filled into it are not. That is also why one policy template can be used by both kinds of company, while copying the content outright always goes wrong — the documents end up carrying someone else's system names, post titles and business objects.

Common misconceptions: one “assumption” on each side

Manufacturing: assuming “once MES is in, data management exists”. This is one of the costlier misjudgements in manufacturing projects. MES solves “work orders move inside the system, reporting leaves a record, batches can be linked”; it does not solve one material with several codes, it does not solve BOM version misalignment, it does not solve production numbers differing across three departments, it does not solve who is accountable for which type of data, and it does not solve the verified closure of quality issues. A system is the carrier for collection and flow; standards, accountability, quality closure and governance mechanisms are not inside the system. The more practical problem is that many companies' MES covers only part of the workshops while others still run on paper; when the interview asks “why is this line not in the system” and no boundary or plan can be given, the credibility of the whole architecture domain drops.

Internet: assuming “having a warehouse means having a data architecture”. A warehouse is part of the architecture, not the architecture itself. What is assessed also includes: the layered design of models and their change records, the data distribution and source systems, a register of integration and sharing interfaces, and automatic metadata collection with lineage. Plenty of teams build a beautiful warehouse, while model changes have no review record, interfaces have no owner, metadata is maintained by hand and has not been updated in three months, and call volumes on data services cannot be stated. Being able to run queries is not the same as having an architecture, and on site the two are easy to tell apart: ask for a table and its upstream and owner, and no answer means it is not there.

A few more misconceptions common to both sides:

• Copying a template. The documents describe data objects and system names that belong to another industry, and it shows at a glance that they were not written here. A management system can be referenced, but not copied.
• Doing only three domains. Governance, security and quality written thickly, with strategy, architecture, application, standards and lifecycle left entirely blank. What is missing is not depth but coverage; the eight domains can be written lightly, but not left unexplained.
• Treating a self-assessment as a conclusion. Every item “substantially conforms”, not one real gap found, and the formal assessment falls over at the first sample. The value of a self-assessment is finding gaps early, not looking good.
• Records concentrated before the assessment. Every meeting minute, inspection report and corrective action falls in the last month or two, and the time span cannot show that the mechanism has been running.
• Turning DCMM into an IT project. A manufacturing company lets only the information department push it, with process, quality and production absent; an internet company lets only the data team push it, with business and legal absent. Both gaps are obvious at the interview stage.
• Stopping once the certificate is issued. An assessment conclusion has a scope of application and a period of validity; if the mechanism stops and the records break, the next reassessment starts from the beginning. Requirements for reassessment and maintenance are subject to the issuing body's rules for the current period.

Action list: do the shared part first, the fork second

The list below is ordered “shared first, fork second”. The way to use it: do the items marked [Shared] first, then work through the [Manufacturing] or [Internet] block for your own industry. Hybrid companies need both blocks, ordered by the share of business.

• ⬜SharedFix the scope: write in one sentence which business, systems and organisational units the assessment covers, and confirm for each “there is data, there is an owner, there are records”
• ⬜SharedFix the people: one lead who can move people across departments, plus one contact for each of the eight capability domains, written down and made known
• ⬜SharedTake stock: a data source list, a system list and a list of main business tables, each with an owning post and a storage location
• ⬜SharedRun the gap analysis: go through the eight domains item by item and produce twenty to thirty concrete gaps, each marked as a policy, execution, record or platform gap
• ⬜SharedBuild the skeleton: a master policy plus domain procedures plus operating forms, accountability assigned to posts and signed, meetings running with a tracking sheet
• ⬜SharedRun one cycle: let the mechanism actually run for a few periods so the records grow; records should span months, not be back-filled in one go
• ⬜SharedCheck across: read names, system names, post titles and dates across the eight sets of material, and remove contradictions and dates that run backwards
• ⬜ManufacturingMaster data: material and supplier first — coding rules, approval path, and a clean-up and cross-reference table for duplicate codes
• ⬜ManufacturingTraceability drill: take one finished goods batch number, trace forward to raw materials and suppliers and backward to shipped customers, within a time limit, recording where it breaks
• ⬜ManufacturingEquipment chain: clock alignment, back-fill rules for network outages, collect at critical operations first, and a point list with an owner
• ⬜ManufacturingAlign definitions: unify production, yield and first-pass yield first, and write the source of the difference into a definition note
• ⬜ManufacturingOutbound and remote: a drawing register, approval and attendance for remote maintenance, and erasure of retired media — all three need records
• ⬜InternetMetric dictionary: core metrics with definition, formula, boundary, owning team and version, and it has to be searchable
• ⬜InternetTracking governance: naming conventions, change review, under-reporting monitoring and user de-duplication rules — all four written down
• ⬜InternetQuality rules: the four rule types live on core tables — primary keys unique, not null, enumerated values, reconciliation — with a closed issue log
• ⬜InternetPersonal information: a field inventory, classification, four-step permission trail, export approval, test data masking
• ⬜InternetExperiments and application: a complete experiment register, a data service catalogue with call volumes, negative metrics on the dashboard too
• ⬜SharedAsk the body: assessment scope, the basis for level judgement, the form of material and scheduling are subject to the assessment body's rules for the current period

Putting the two kinds of company side by side, the conclusion is plain: DCMM never checks whether you own a set of data management documents, but whether you know what data you have, who is touching it, whether it is accurate, and what it has changed. When an internet company answers those four questions, the answers are largely inside systems; when a manufacturing company answers the same four questions, half the answer is inside systems and half is on the shop floor. Work out which one you are, and the preparation will not start from the wrong list, and will not be stopped on site by a single “so who actually does this”.

▍Not sure which set to prepare against? Leave a comment noting “industry comparison”, send us your main business, organisation size and main systems, and we will send back a data source list framework and a scenario question set for your industry.