简介：本资源是一份面向医药、GMP合规及SAP系统实施人员的专业技术PPT，聚焦电子签名（Electronic Signatures）与电子记录（Electronic Records）在SAP ERP系统中的合规落地路径，核心解决FDA 21 CFR Part 11认证场景下的系统设计与验证难题。PPT由SAP AG官方于2007年发布，系统梳理了Part 11对签名安全性、不可否认性、记录可追溯性与审计追踪的强制要求，并结合SAP ERP架构详解实现策略，包括数字证书集成、签名流程嵌入、审计日志配置及验证要点。资源为单文件PPT格式，共1个文件，大小3.7MB，内容结构完整，涵盖法规背景、合规趋势（如FDA 2003年草案指引）、典型缺陷案例（1999–2001年警告信增长分析）及SAP具体实现模块示意。目前已有578人学习下载，适合从事制药行业SAP项目实施、系统验证（CSV）、质量合规（QA/QC）及IT审计的技术人员快速掌握FDA合规关键控制点与SAP适配方案。
1. 电子签名和电子记录在SAP里到底是什么：不是“点个确认框”就完事的法律凭证
你有没有遇到过这样的场景：
在药厂的SAP系统里，质量经理刚审批完一批原料的检验结果，点击“确认”——系统弹出一个绿色对勾，流程就往下走了。表面看，一切丝滑；但审计老师突然坐到你工位旁，打开审计日志，问：“这个‘确认’，凭什么算法律意义上的签名？谁点的？什么时候点的？点之前数据有没有被悄悄改过？改了哪一行、从多少变成多少？这个操作能不能还原成纸质档案里那种‘张三亲笔签署、2024年6月12日14:32分、注明‘已复核无误’’的效果？”
这时候，如果答不出，就不是技术问题，而是合规风险。
电子签名（Electronic Signature）和电子记录（Electronic Record）在SAP中，从来不是功能开关或UI按钮，而是一整套可验证、可追溯、不可抵赖的证据链设计。它源于美国FDA的21 CFR Part 11法规——简单说，就是告诉所有做药品、医疗器械的企业：“你们用电脑代替纸笔，没问题；但电脑留下的痕迹，必须比手写签名+红章+骑缝章+专人保管还更牢靠。”
这不是IT部门加个密码框就能交差的事。它要求：每一次关键操作（比如批准放行、修改配方、关闭偏差），系统必须自动捕获“谁、在什么精确到秒的本地时间、以什么身份（审核/批准/授权）、对哪条数据做了什么动作（新增/修改/删除）、改前改后值分别是多少”，且这些信息必须独立存储、防篡改、长期保留、随时能导出供监管检查。
换句话说：SAP里的电子签名，是法律认可的“数字指纹+时间戳+行为说明书”三合一；电子记录，则是这套指纹所依附的、带全生命周期轨迹的“数字档案袋”。
搞不清这个本质，后续所有配置、验证、审计应对，都会像在流沙上盖楼——看着漂亮，一查就塌。
2. 为什么SAP必须认真对待电子签名和电子记录：FDA不是在考技术，是在验责任
2.1 FDA管的从来不是“电脑好不好用”，而是“证据能不能当庭作证”
很多人误以为21 CFR Part 11是IT标准，其实它根本不是。它的底层逻辑叫“Predicate Rule（前提规则）”——意思是：FDA先有一堆行业基本法（比如GMP《药品生产质量管理规范》），规定“批记录必须保存5年”“检验结果必须经QA复核签字”；Part 11只是补充一句：“如果你用电子方式干这事，那你的电子方式，得达到甚至超过纸质方式的法律效力。”
所以，SAP里哪些模块要上电子签名？不是看“用了没用系统”，而是看“这个操作是否对应GMP里白纸黑字的责任条款”。
举个真实案例：某药企在SAP的QM（质量管理系统）里创建“检验计划”，但没启用签名控制。审计时发现：该计划直接决定10万支注射液的放行标准。FDA立刻指出——这等同于让一个没签字的空白处方单去指挥生产线。风险不在系统多先进，而在责任链条断了。
提示：Part 11不强制所有SAP操作都签名，只强制“GMP相关、影响产品质量或患者安全”的操作。判断依据不是模块名（如QM模块），而是业务实质（如“批准最终检验报告”）。
2.2 “等效性”原则：电子方式必须比纸质更可靠，而不是差不多
Part 11最常被低估的一条是§11.10(b)：“必须能生成准确、完整的记录副本，供检查、审阅和复制。”
听起来普通？但现实中，很多SAP客户栽在这儿。比如：
- 系统导出的PDF检验报告里，只显示当前状态，不包含历史修改痕迹；
- 审计日志存在数据库里，但导出时需手动拼接多张表，且时间戳格式混乱（有的用UTC，有的用服务器本地时，有的缺毫秒）；
- 更隐蔽的是：SAP标准事务码（如MBST冲销物料凭证）本身不带签名，但企业用自定义报表批量处理时，却没同步记录操作人和时间。
这些都不是“功能缺失”，而是对“等效性”的理解偏差——纸质档案里，你撕掉一页，整本档案就缺页；但电子世界里，删一条日志可能神不知鬼不觉。所以Part 11要求：电子记录的“副本”，必须自带完整上下文（含审计追踪），且格式必须是监管方开箱即用（比如标准XML或CSV，而非只有SAP才能打开的二进制文件）。
2.3 FDA的执法哲学：抓大放小，但“大”是生死线
2003年FDA发布《Part 11适用范围指南》，明确释放三个关键信号：
- 窄化解释：不把Part 11当成“所有IT系统都要套的紧箍咒”，只聚焦直接影响产品安全的环节；
- 执法裁量：对“验证、审计追踪、留存期限”等要求，会视企业成熟度灵活处理；
- 溯及既往豁免：老系统（Part 11生效前上线）若未改造，暂不追责。
但这绝不意味着可以松懈。看一组数据：1999年FDA发出72封警告信，其中GMP相关缺陷里，验证与资质问题占7%；到2001年，同类警告信暴增至720封，比例升至23%。增长的不是问题数量，而是监管对电子证据链完整性的容忍度归零。
今天被盯上的，往往不是“完全没做”，而是“做了但漏了关键一环”——比如：
- 有签名，但没记录“签名含义”（是批准？复核？还是仅查看？）；
- 有审计日志，但没保护日志本身（允许管理员直接删库）；
- 有时间戳，但跨时区场景下，没按Part 11要求同时记录“全球时间+签署人本地时间”。
这些细节，在内部测试时毫无感觉；一旦FDA现场审计，就是一票否决项。
3. 电子签名 vs 数字签名：别再把加密算法当合规答案
3.1 核心区别：法律效力来源不同，技术实现只是工具
这是初学者踩坑最多的地方。翻看SAP文档，常看到“支持PKI数字证书”“集成RSA加密”，于是团队立刻采购CA证书、部署签名服务器……结果审计时被问：“你们用数字签名，解决了Part 11哪条具体要求？”全场哑火。
真相是：
- 电子签名（Electronic Signature）是法律概念，指“任何电子形式的、表明签署人意图的符号”（比如SAP里的“审批”按钮、邮件回复“同意”、甚至扫描的手写签名图）。它的效力取决于流程设计是否满足Part 11全部要求（双因子认证、行为绑定、不可否认等）。
- 数字签名（Digital Signature）是技术概念，特指基于非对称加密（如RSA）的数学签名，核心价值是验证数据完整性+身份认证。但它本身不解决“谁在什么时间点了什么”——这需要SAP业务逻辑配合。
打个比方：
电子签名像一份公证过的合同，重点是“签的过程合法、内容可验、反悔不了”；
数字签名像合同上的防伪水印，只保证“这张纸没被PS过”，但不证明“签字人真是张三，也没记录他几点签的”。
SAP原生支持的电子签名机制（如SU01用户锁定、SM19审计日志、GRAC权限管控），恰恰是绕开复杂加密、用业务层控制达成合规的典范——它不追求“高大上技术”，而专注“每一步操作都有迹可循”。
3.2 SAP里真正的电子签名实现：三道防线缺一不可
Part 11 §11.200(a)要求：“非生物识别类电子签名，须至少含两个独立识别要素（如ID+密码）”。SAP的落地不是靠插件，而是靠体系化配置：
第一道防线：身份强管控（Who）
- 用户ID与真实员工一一绑定（禁用共享账号，如“TEST_USER”）；
- 密码策略强制：最小长度8位、含大小写字母+数字、90天强制更换、历史密码禁止重复；
- 登录失败5次自动锁户（事务码SU01配置），并实时邮件告警给安全管理员。
第二道防线：行为强绑定（What & When）
- 关键事务码（如QA32检验批审批、CO02生产订单确认）启用“签名必填”；
- 签名时自动捕获：操作人ID、服务器时间戳、客户端本地时间戳（通过SAPGUI参数
login/system_client_time获取）、签名含义（预设选项：批准/复核/授权）； - 所有签名事件写入独立审计表（如CDHDR/CDPOS），与业务数据物理隔离。
第三道防线：证据强固化（Proof）
- 审计日志开启“不可删除”模式（SM19设置
Log deletion not allowed）； - 导出功能强制包含：原始业务数据+完整变更历史（含旧值/新值）+签名元数据（ID/时间/含义）；
- 每季度执行“日志一致性校验”：用ABAP程序比对CDHDR中的对象变更数，与业务表（如MSEG物料凭证）的更新次数是否匹配。
注意：很多企业只做第一道防线（改密码策略），却忽略第二、三道。结果是——人是实名的，但“点了什么”“点了几次”“点完改没改”全无记录，等于白做。
3.3 常见误区：5个让审计老师当场皱眉的混淆点
| 易混点 | 为什么混 | 怎么区分 |
|---|---|---|
| “用了数字证书=满足Part 11” | 误把技术手段当合规终点。数字证书只解决“身份真伪”，不解决“操作意图”“时间精度”“审计留存”。 | Part 11要求签名必须关联“行为含义”（如“批准”而非“查看”），且时间戳需精确到秒、含本地时区。纯证书方案若没在SAP层绑定这些字段，就是无效签名。 |
| “SAP标准审计日志=Part 11审计追踪” | SAP默认日志（SM19）记录登录/退出，但GMP关键操作（如修改BOM）需单独开启表日志（SCU3），且默认不存“旧值/新值”。 | Part 11 §11.10(e)明确要求“记录变更前后的值”。必须用SCU3为关键表（如STKO工艺路线）开启“Change Document”，并确保CDPOS表存储完整差异。 |
| “导出PDF报告=满足副本要求” | PDF是呈现格式，不等于证据载体。Part 11要求副本必须含“可机读的审计追踪”，PDF若无嵌入日志数据，就是废纸。 | 合规副本必须是结构化数据（如XML），含业务数据+CDHDR/CDPOS关联ID+签名元数据。PDF仅作辅助阅读，不能替代。 |
| “管理员权限=可绕过签名” | 认为“超级用户”可以跳过流程。Part 11 §11.300(d)严禁“未经授权使用ID”，管理员操作同样需留痕。 | SAP中所有后台修改（如SE16N直接改表）必须通过专用事务码（如SCU01）并强制签名，且日志独立存储。禁用直接数据库操作。 |
| “系统没报错=签名有效” | 忽略签名含义的业务语义。例如：同一ID对采购订单点“审批”，但系统未配置“审批=质量放行”，则该签名无GMP效力。 | 签名必须与GMP责任条款映射。需在SAP IMG中为每个签名点配置“签名含义字典”（如TQ80），并与质量手册条款挂钩，审计时可追溯。 |
4. SAP中电子记录的四大生命阶段：从创建到销毁，每一步都是证据
4.1 创建阶段：不是“存进去”就算数，而是“怎么存”决定法律效力
Part 11 §11.10(a)定义电子记录为：“以数字形式创建、修改、维护、归档、检索或分发的文本、图形、数据、音频、图像等信息组合。”
在SAP中，这覆盖远超想象：
- 配置类：IMG实施指南里的参数设置（如OMJ2定义批次管理策略）；
- 主数据类：物料主数据（MM01）、供应商主数据（XK01）、工艺路线（CA01）；
- 交易类：采购订单（ME21N）、生产订单（CO01）、检验批（QA01）；
- 过程类：变更通知（ECM）、偏差报告（DMS）、CAPA记录（QM01）。
关键陷阱在于：SAP默认不自动记录“谁创建了这条记录”。比如用LSMW批量导入物料主数据，若脚本没调用BAPI_MATERIAL_SAVEDATA并传入username参数，系统只会记“系统用户”，无法追溯责任人。
正确做法：
- 所有批量导入必须走BAPI或IDoc，且强制填充
username字段； - 自定义报表修改数据时，必须调用
SY-UNAME获取当前用户，并写入自定义日志表； - 对于SAP标准事务码（如MM01），启用“用户字段增强”（如CI_MARA），将
SY-UNAME自动写入扩展字段。
4.2 修改阶段：审计追踪不是“有就行”，而是“有且全、有且准”
Part 11 §11.10(e)要求审计追踪必须独立记录：
- 操作人ID；
- 操作时间（精确到秒）；
- 事务类型（插入/删除/修改）；
- 变更详情（旧值→新值）；
- 日志保留期≥记录本身保留期。
SAP提供三种日志机制，但能力天差地别：
| 机制 | 覆盖范围 | 是否存旧值/新值 | 是否独立存储 | Part 11符合度 |
|---|---|---|---|---|
| SM19系统日志 | 登录/退出/参数修改 | ❌ 仅记录事件，无数据详情 | ✅ 独立表 | 低（仅满足基础访问控制） |
| SCU3表日志 | 指定数据库表（如MARA） | ✅ 可配置存差异 | ✅ 独立CDHDR/CDPOS表 | 中（需手动开启+验证） |
| 变更文档（Change Document） | 业务对象（如物料主数据） | ✅ 自动存完整变更链 | ✅ 独立CDHDR/CDPOS表 | 高（SAP原生推荐） |
实战建议：
- 对GMP关键表（如MARA物料主数据、AUFK生产订单头），必须启用变更文档（事务码OMCG配置）；
- 验证方法：用MM02修改物料描述，然后查CDHDR表，确认
OBJECTCLAS='MATERIAL'且CHANGENR有值；再查CDPOS表，确认VALUE_OLD和VALUE_NEW字段非空； - 禁用SCU3表日志替代方案——它虽能存差异，但需DBA手动维护，且不与业务对象关联，审计时难以解释。
4.3 归档阶段：不是“压缩打包”，而是“证据链冻结”
Part 11 §11.10(b)强调“副本必须可供检查”，隐含要求：归档后的电子记录，必须保持原始可读性+可验证性。
SAP常用归档方案（如SARA）存在致命缺陷：
- 归档后，原始事务码（如MB51查物料凭证）无法再访问归档数据；
- 归档包（如ARCHIVEFILE）是SAP专有格式，FDA检查员无法用通用工具打开；
- 更严重的是：归档过程本身若没签名，就构成“证据链断裂”。
合规解法：
- 归档前强制签名：在SARA归档作业（SA38运行
RSAR_ARCHIV_CREATE）前，增加ABAP检查点，调用BAPI_ARCHIV_CHECK验证所有待归档对象均有完整审计日志； - 归档包双轨制：除SAP归档包外，同步生成标准XML副本（含业务数据+CDHDR/CDPOS关联ID），用SHA-256哈希值校验完整性；
- 归档后访问通道：开发专用报表（如ZARCHIVE_VIEW），输入归档ID即可调取XML副本+原始日志链接，确保“查得到、验得准”。
4.4 销毁阶段：不是“删库跑路”，而是“合规焚毁”
Part 11未规定销毁流程，但GMP要求“记录保存期满后安全销毁”。SAP中常见错误：
- 直接DELETE FROM MSEG WHERE ...（绕过业务逻辑，审计日志无记录）；
- 用SARA删除归档包，但未同步清除CDHDR/CDPOS中对应日志。
正确姿势：
- 销毁必须走SAP标准归档删除程序（SA38运行
RSAR_ARCHIV_DELETE），该程序会自动记录删除操作到SM19； - 删除前，生成销毁清单（含对象ID、销毁时间、操作人），由QA和IT双签；
- 最关键一步：在销毁清单上，用SAP数字签名工具（如SAP GUI签名控件）添加电子签名，注明“本人确认该批记录已按GMP第X章第Y条销毁”，使销毁行为本身成为可追溯的电子记录。
5. 什么时候必须上电子签名/记录，什么时候可以暂缓：一张决策表帮你避开80%的翻车
5.1 判断铁律：只看“是否触发GMP责任条款”，不看“是否在SAP里”
很多团队陷入“技术驱动”陷阱：看到SAP有签名功能，就给所有事务码加锁。结果是——业务抱怨流程变慢，IT疲于救火，而真正该管的环节反而漏了。
核心判断法：拿出企业《质量手册》，找到所有带“必须”“应当”“经批准”的条款，逐条映射到SAP操作。例如：
| GMP条款原文（节选） | 对应SAP操作 | 是否必须电子签名/记录 | 理由 |
|---|---|---|---|
| “批生产记录必须经生产负责人和质量负责人共同审核批准后方可放行” | CO02生产订单确认 + QA32检验批审批 | ✅ 必须 | 直接决定产品放行，属最高风险环节 |
| “供应商资质文件应定期更新并存档” | XK02修改供应商地址 | ⚠️ 视情况 | 若地址变更影响GMP（如物流温控），则需；若仅更新邮箱，则无需 |
| “设备清洁记录应保存至产品有效期后一年” | QM01创建清洁记录 | ✅ 必须 | 清洁记录是GMP硬性要求，电子版必须等效 |
| “IT系统变更需经变更控制流程批准” | SE09传输请求审批 | ✅ 必须 | 系统变更影响数据可靠性，属Part 11直接管辖 |
| “员工培训记录应由HR和部门负责人签字” | PA30维护培训状态 | ✅ 必须 | 培训有效性直接影响GMP执行，签名是责任锚点 |
提示：对“视情况”项，建立《GMP影响评估矩阵》，由QA牵头，每季度评审一次。避免凭经验拍板。
5.2 实施优先级：从“审计高频项”开始，不做全量覆盖
FDA检查有明确偏好：80%的Part 11问题集中在5个领域——
- 批记录相关（生产/检验/放行）；
- 主数据变更（物料/BOM/工艺路线）；
- 偏差与CAPA管理；
- 电子签名含义缺失；
- 审计日志未保护（可被删除）。
因此，资源有限时，按此顺序攻坚：
- 第一阶段（1个月内）：锁定QM（检验批）、PP（生产订单）、MM（物料主数据）三大模块，启用变更文档+签名必填；
- 第二阶段（2个月内）：打通DMS（偏差）、CAPA（纠正预防）流程，确保每个状态变更带签名+时间戳；
- 第三阶段（3个月内）：完成审计日志加固（SM19+SCU3双启用）、归档方案验证、销毁流程签名化。
切忌一上来就搞“全系统签名”，那是用IT成本换虚假安全感。
5.3 一个血泪教训：我们如何因漏掉“签名含义”被FDA开出483表
去年，某药企接受FDA现场检查。我们自认准备充分：所有关键事务码启用了签名，审计日志开启，导出功能正常。直到检查员随机抽样一份“工艺参数变更单”（SAP中用ECM模块），问：“这个签名，代表什么？”
我们答：“是批准变更。”
检查员追问：“批准什么？是批准变更申请？还是批准变更生效？还是批准变更后的新参数？”
我们愣住——SAP里确实只有一个“批准”按钮，但没配置签名含义字典。系统日志里只记SIGNATURE_TYPE='APPROVE'，没说明是哪个环节的批准。
结果：FDA认定“签名无法体现操作人真实意图”，开出483观察项：“Electronic signatures do not clearly indicate the meaning associated with the signature as required by §11.50(a).”
从那以后，我每次配置新签名点，都强制走三步：
- 在IMG中进入“Quality Management → Basic Settings → Electronic Signatures”，为该事务码创建专属签名含义（如
ECM_APPROVE_REQUEST）； - 在SAP GUI前端，为签名按钮添加语义化标签（如“批准变更申请：仅表示同意启动变更，不表示参数已生效”）；
- 将该含义写入质量手册附件，并培训所有用户——不是教他们点哪里，而是教他们“点这个，就等于签了哪份责任书”。
希望帮到你。
本文还有配套的精品资源，点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
