行业现状与产品约束

1. 文档目的与使用边界

本文档用于给内部产品研发团队提供起重机械行业真实运行现状、监管断点、灰色场景与产品设计约束的基础认知，帮助后续系统设计更贴近落地环境。

本文档不是设备来源处理指南、手续补做指南或规避监管操作说明。凡涉及无证运行、资料造假、套证套码、隐瞒真实状态等行为，均属于高风险违法违规事项。本文件仅将其作为行业现实与风险场景进行识别，用于指导系统边界设计、状态管理和审计留痕设计。

2. 为什么产品设计不能脱离现状

在起重机械行业，设备状态并不总是简单分成“完全合规”与“完全非法”两类。现实中同时存在：

• 历史遗留设备；
• 手续不完整但仍在使用的设备；
• 已检验但未完成使用登记的设备；
• 被厂家、中间商或代办误导后形成被动违规状态的设备；
• 资料缺失、状态不清、整改中但仍需维持生产的设备。

如果系统只支持理想化流程，例如“设备建档前必须资料完整”“没有登记证就无法录入任何记录”“不允许任何历史补录”，很容易出现两个后果：

1. 现场根本无法使用，业务被迫绕开系统；
2. 实际风险被藏在系统外，平台反而失去价值。

因此，产品应坚持合规底线，但也必须承认现实中的非理想状态，并为识别、标记、整改、留痕提供机制。

3. 行业内常见设备合规状态分类

3.1 三无新机

常见特征：来源不明、缺少合格证明、型式试验资料、正规出厂手续等基础资料。

对产品的意义：

• 需要支持“资料严重缺失”的风险状态标记；
• 不能因为缺证就把设备从系统中“抹掉”；
• 应强制记录来源不明、不可投入正常运行等风险结论。

3.2 报废翻新机

常见特征：设备经过外观翻新、部件更换或重新标识后再次流通，外观上难以直接判断历史状态。

对产品的意义：

• 设备身份信息不能只依赖人工输入名称；
• 应把铭牌信息、来源资料、关键照片、历史检验记录作为档案的一部分；
• 需要支持“身份存疑”“需核验原始来源”的状态。

3.3 脱审黑户机

常见特征：曾经有手续，但长期未检、未登记更新、私下转让后脱离日常监管。

对产品的意义：

• 需要记录设备的最近一次检验、登记、维保、转移等时间点；
• 必须支持超期预警、失管预警、状态降级；
• 应区分“曾合规但已失管”与“从未合规”两类风险。

3.4 手续套用机

常见特征：设备资料与实体设备不一定一一对应，存在证照、报告、编码被重复引用的风险。

对产品的意义：

• 应强调一机一档、一档一身份；
• 同一证照、同一设备编码、同一检验报告不得被多个设备主档重复绑定；
• 重要附件与设备身份需要建立唯一关联规则。

3.5 有检无证机

常见特征：设备可能完成了出厂和检验环节，但未继续完成使用登记，导致设备在系统外运行。

这是最值得产品重视的一类现实场景，因为它最接近“手续看起来不少，但监管链条并未闭合”的状态。

对产品的意义：

• 必须把“检验合格”与“已办理使用登记”拆成两个独立状态字段；
• 不能默认“有检验报告=可以投入正常使用”；
• 应针对未登记设备提供持续提醒、整改待办和风险提示。

3.6 被动违规机

常见特征：使用单位原本希望合规，但因厂家、中间商、代办或内部管理失误，错过告知、报检、登记、台账等关键节点，后续处于被动违规状态。

对产品的意义：

• 系统不能只考虑主观恶意场景；
• 需要支持“待补资料”“待整改”“历史缺口说明”等中间状态；
• 需要保留问题来源、责任归因、整改过程，帮助企业回到合规轨道。

4. 监管链路中的主要断点

以下内容只描述监管断点和产品应对重点，不提供操作路径。

4.1 设备进入现场之前的信息断点

在设备采购、转让、翻新、安装前阶段，信息往往分散在厂家、经销商、代办、使用单位之间。此时如果没有统一归档，设备身份很容易在最早阶段就出现模糊。

产品约束：

• 建档时应支持记录来源渠道、供货单位、制造单位、安装单位；
• 关键资料缺失时仍允许建“风险档案”，但必须带状态标签；
• 档案中应保留原始附件和版本信息。

4.2 安装与告知阶段的流程断点

部分问题不是出在设备本体，而是出在流程节点没被管理起来，例如安装告知、监督检验、资料移交责任不清。

产品约束：

• 需要把安装前、安装中、安装后拆成阶段状态；
• 对缺少关键节点资料的设备给出不可忽略的风险提示；
• 应记录由谁负责补齐、截止时间是什么。

4.3 使用登记前的监管断点

行业里常见的误区是把检验通过当成全部流程完成，而忽略使用登记这一强制环节。

产品约束：

• 设备状态至少要拆成：待建档、待检验、检验合格待登记、已登记可用、超期待检、停用待处置；
• 报表与列表页必须清楚展示“未登记但在运营”的风险状态；
• 不能把未登记设备混入正常合规设备统计口径。

4.4 日常台账阶段的管理断点

现实中，很多问题不是设备完全没有检查，而是检查、维保、签字、归档没有形成稳定留痕，最后导致“做了但说不清”“查的时候拿不出”。

产品约束：

• 日检、月检、维保、年度自检应形成固定任务与记录结构；
• 签字、附件、完成时间、执行人、安全员确认要有明确字段；
• 系统必须支持查询和导出，不让记录散落在聊天、纸张、个人电脑里。

4.5 历史资料补录阶段的审计断点

实际业务中，历史资料不完整是高频问题。系统如果完全不允许补录，现场会绕开系统；但如果允许无痕补录，又会破坏真实性。

产品约束：

• 允许历史补录，但必须保留：补录时间、补录人、补录原因、原始时间；
• 需要区分“记录发生时间”和“录入时间”；
• 对补录记录应支持统一筛选与审计，不得和实时记录无差别混在一起。

5. 产品设计必须面对的核心约束

5.1 系统要承认异常状态存在

产品不能只服务“完美合规设备”。

应支持的状态至少包括：

• 资料不全；
• 身份待核验；
• 检验已完成但待登记；
• 超期未检；
• 历史记录待补；
• 整改中；
• 停用；
• 禁止投入运行。

5.2 系统要把风险显性化，而不是替用户掩盖问题

好的系统不是把不合规状态藏起来，而是：

• 明确标记风险；
• 区分问题类型；
• 给出整改任务；
• 保留整改闭环过程。

5.3 系统要允许历史补全，但必须审计留痕

历史补录是现实需求，但必须是“可解释、可追溯、可审计”的补录。

设计要求：

• 原始记录时间与实际录入时间分离；
• 补录原因必填；
• 补录操作必须记录操作者；
• 后续导出时可区分正常记录与补录记录。

5.4 系统要区分“设备存在”与“设备合规可用”

很多系统一开始就把“没证设备”挡在建档之外，结果设备仍在现场，系统却看不见。

正确做法应是：

• 允许设备建档；
• 但通过状态、权限、预警、统计口径明确其不可视为合规运行设备；
• 让系统成为问题暴露和整改抓手，而不是问题掩盖工具。

5.5 系统要支持一机一档，但不能假设初始资料天然完整

一机一档是目标状态，不是所有设备的初始状态。

设计要求：

• 档案应允许从“基础主档”逐步补齐至“完整档案”；
• 关键字段缺失时要标明“待补”；
• 对核心证照、检验报告、登记信息设置完整性校验规则。

6. 对后续系统设计的直接指导

6.1 对台账系统的指导

第二份台账系统需求文档应直接吸收本文约束，至少体现：

• 设备状态分层；
• 补录留痕；
• 检验与登记状态分离；
• 风险预警；
• 整改闭环；
• 电子档案可追溯。

6.2 对标准电气系统项目的指导

第三份项目框架文档应把“档案与合规体系”视为与电控底层同等重要的组成部分，而不是后加附件。标准电气系统项目不能只做图纸、BOM 和 PLC，也要考虑：

• 设备主档身份如何建立；
• 交付资料如何成套归档；
• 后续检验、登记、维保记录如何接入；
• 为未来监管平台或校方平台对接预留什么数据接口。

7. 产品侧底线原则

后续所有系统设计都应遵守以下底线：

1. 不帮助伪造、套用、隐瞒设备身份与资料；
2. 不把违法违规状态包装成“合规流程”；
3. 不删除、不覆盖关键历史痕迹；
4. 支持异常状态录入，但必须同步风险标记；
5. 支持整改回归合规，而不是帮助长期停留在灰色状态；
6. 所有补录、修改、附件替换均应保留审计信息。

8. 可转化为产品规则的建议清单

后续可直接转成系统需求的规则包括：

• 设备主档必须有状态字段，且状态不能只有“启用/停用”；
• 检验状态、登记状态、维保状态、台账完整性状态应拆分；
• 允许录入历史记录，但必须记录补录信息；
• 一份关键证照原则上只能绑定一台设备主档；
• 风险设备必须进入专门列表和预警范围；
• 导出资料时应能显示档案完整度与异常项；
• 对“待整改设备”应支持责任人、截止时间、整改结果管理。

9. 结论

这份行业现状材料对产品研发最重要的启发，不是“别人怎么绕监管”，而是：系统必须在坚持合规底线的同时，承认现场存在大量非理想状态，并把这些状态纳入可识别、可追踪、可整改的数字化管理体系。

只有这样，系统才不会因为过度理想化而失去落地能力，也不会因为迎合灰色现实而失去合规价值。