09 AI审计平台设计从风险识别出发而非从底稿编号出发摘要如果你打开一个审计系统首页显示的是E1000、E2000、E3000这些底稿编号那这个系统的设计者一定没搞明白审计师每天到底在想什么。我做了八年审计系统UX设计访谈过上百个审计师发现一个规律审计师早上睁开眼想的不是今天该填哪张底稿而是这个项目还有哪些雷没排完。这篇文章从用户体验的第一性原理出发讲清楚审计平台界面设计的核心逻辑——不是让界面更漂亮是让审计师更快找到该排的雷。文章标签审计平台设计AI审计用户体验审计系统审计底稿风险识别审计平台产品设计关键字审计平台设计, AI审计, 用户体验, 审计系统, 审计底稿, 风险识别, 审计平台, 产品设计, 审计数字化, 审计风险一、底稿编号导向的荒谬我见过一个审计系统登录后的首页是这样的-------------------------------------------------- | 某审计系统首页底稿编号导向 | -------------------------------------------------- | | | 欢迎使用XX审计系统 | | | | 我的待办15项未开始 | | ├─ E1000 货币资金底稿 │ | ├─ E2000 应收账款底稿 │ | ├─ E2100 坏账准备底稿 │ | ├─ E3000 存货底稿 │ | ├─ E3100 存货跌价准备底稿 │ | ├─ E4000 固定资产底稿 │ | └─ ... │ | | | 已完成的底稿23项 │ | 项目进度23/38 60% │ | | --------------------------------------------------这个设计有什么问题问题是审计师的工作不是填底稿是管理风险。当审计师看到E1000货币资金底稿的时候他脑子里想的是“哦今天要填货币资金底稿。”但正确的想法应该是“货币资金这个科目存在性和完整性风险处理得怎么样了证据够不够有没有异常”底稿编号导向的设计把审计师从风险管理者降级成了底稿填写员。更荒谬的是有些系统把底稿编号当成了导航的核心。审计师要找到一个风险点需要先记住这个风险点属于哪个底稿然后再去底稿列表里找。这就像医院的信息系统护士打开系统看到的是一个表单列表“体温记录表”“血压记录表”“用药记录表”——而不是3床病人今天有哪些异常指标需要关注。二、审计师的一天应该是怎样的让我们站在审计师的角度想想他一天的工作应该是怎样的。早上8:30打开系统底稿编号导向的系统系统提示您有15个底稿待完成今天建议完成E1000和E2000。审计师的想法“好吧打开E1000看看今天要填什么。”风险导向的系统-------------------------------------------------- | 今日风险提醒 | -------------------------------------------------- | | | 您负责的项目有3个高风险事项需要关注 | | | | [高] 收入确认截止性风险 | | 12月收入占全年35%远超行业平均20% │ | → 需要确认12月最后一周的发货是否真实 │ | → 建议追加程序获取物流签收记录 │ | │ | [中] 应收账款坏账准备 │ | 计提比例5%但历史回款率98%存在矛盾 │ | → 需要判断计提比例是否过高 │ | │ | [中] 存货跌价准备 │ | 系统已自动获取市场价格数据 │ | → 需要复核管理层估计的可变现净值 │ | │ | 【您今天的工作建议】 │ | 1. 优先处理收入确认截止性风险高风险 │ | 2. 联系客户获取12月最后一周的物流签收记录 │ | 3. 下午2点项目组会议讨论收入异常 │ | 4. 昨日未完成复核存货跌价准备测试底稿 │ | │ | 【昨日动态】 │ | ✅ 已完成货币资金存在性验证 │ | ✅ 已完成银行询证函回函核对23/25 │ | │ --------------------------------------------------审计师的想法“收入风险这么高了得赶紧处理。”两种设计的本质区别前者告诉审计师你要做什么后者告诉审计师你应该关注什么。上午10:00处理风险底稿编号导向的系统审计师打开E1000货币资金底稿按模板要求逐项填写。填到银行对账单核对这一栏打开附件里的银行对账单PDF人工核对数字。风险导向的系统审计师点击收入确认截止性风险系统展示-------------------------------------------------- | 风险收入确认截止性 | -------------------------------------------------- | | | 【风险等级】高 │ | 【涉及认定】截止、发生 │ | 【涉及科目】主营业务收入 │ | │ | 【为什么有这个风险】 │ | ├─ 准则要求CAS 14 第9条 │ | ├─ 系统识别12月收入占全年34.7% │ | ├─ 行业对比同行业12月平均占比18-22% │ | ├─ 历史对比去年12月占比25% │ | └─ 审计师备注年末突击确认收入的可能性 │ | │ | 【系统已采集的证据】 │ | ├─ 12月销售合同 15份 │ | ├─ 12月发货单 120份 │ | ├─ 12月发票 120张 │ | └─ 物流签收记录部分缺失 │ | │ | 【系统标记的异常】 │ | ⚠ 12月25日后的5笔发货单无物流签收记录 │ | ⚠ 3家12月新增大客户合同金额均超500万 │ | ⚠ 12月最后一周确认收入占12月总收入60% │ | │ | 【建议追加程序】 │ | 1. 获取缺失的物流签收记录 │ | 2. 访谈3家新增大客户 │ | 3. 检查期后退货情况 │ | │ | 【审计师判断】 │ | □ 异常可解释风险可控 │ | □ 异常需要进一步调查 │ | └─ 追加程序________________________ │ | │ --------------------------------------------------审计师的工作是查看系统整理好的证据和异常判断是否需要追加程序形成结论。不是打开空白底稿模板从零开始收集和整理证据。下午3:00经理复核底稿编号导向的系统经理打开审计师填好的E1000逐行检查数字对不对、格式规不规范、签字齐不齐。风险导向的系统经理打开项目风险仪表板看到-------------------------------------------------- | 项目风险状态 - 复核视图 | -------------------------------------------------- | | | 项目经理张三 │ | 待复核风险处理5个 │ | │ | ┌──────────────────────────────────────┐ │ | │ ✅ 货币资金存在性 │ │ | │ 状态已确认 审计师李四 │ │ | │ 结论证据充分无异常 │ │ | │ 一键复核 │ │ | └──────────────────────────────────────┘ │ | │ | ┌──────────────────────────────────────┐ │ | │ ⚠ 收入确认截止性高风险 │ │ | │ 状态待复核 审计师李四 │ │ | │ 结论异常需调查已追加4项程序 │ │ | │ 点击查看详情 → │ │ | │ │ │ | │ 【追加程序执行情况】 │ │ | │ 1. ✓ 已获取5份缺失物流记录 │ │ | │ 2. ✓ 已访谈3家新增客户 │ │ | │ 3. ✓ 期后退货3笔金额120万 │ │ | │ 4. ○ 截止测试中2笔收入确认时点存疑 │ │ | │ │ │ | │ 【经理复核意见】 │ │ | │ □ 同意审计师结论 │ │ | │ □ 需要补充请说明_____________ │ │ | │ □ 需要升级至合伙人 │ │ | └──────────────────────────────────────┘ │ | │ | 关键指标 │ | ├─ 高风险风险处理率60% │ | ├─ 证据充分率75% │ | └─ 异常待处理2个 │ | │ --------------------------------------------------经理的复核逻辑变了不是检查底稿填没填对而是检查风险处理得是否充分、判断是否合理。三、从底稿编号到风险识别的设计转变要实现从底稿编号导向到风险导向的设计转变需要在三个层面做出改变第一层信息架构的重构-------------------------------------------------- | 信息架构对比 | -------------------------------------------------- | | | 底稿编号导向的信息架构 │ | ├─ 项目 │ | │ ├─ 底稿 E1000 货币资金 │ | │ ├─ 底稿 E2000 应收账款 │ | │ ├─ 底稿 E3000 存货 │ | │ └─ ... │ | │ 风险信息分散在各底稿中 │ | │ | 风险导向的信息架构 │ | ├─ 项目 │ | │ ├─ 风险假设 │ | │ │ ├─ 货币资金存在性 │ | │ │ ├─ 应收账款可收回性 │ | │ │ ├─ 收入确认截止性 │ | │ │ └─ ... │ | │ ├─ 证据池 │ | │ ├─ 判断记录 │ | │ └─ 底稿视图按需生成 │ | │ 风险是中心底稿是视图 │ | │ --------------------------------------------------第二层界面设计的重构底稿编号导向的界面逻辑打开底稿 → 填写内容 → 保存 → 提交复核 ↑_____________________________| 循环往复底稿是工作的中心风险导向的界面逻辑查看风险 → 查看证据 → 做判断 → 确认风险处理完毕 ↑______________________________________| ↓ 自动生成对应底稿第三层工作流的重构-------------------------------------------------- | 工作流对比 | -------------------------------------------------- | | | 传统工作流底稿驱动 │ | │ | 项目经理分配底稿 → 审计师填写底稿 │ | ↓ │ | 审计师向客户要资料 → 整理数据 → 填入底稿 │ | ↓ │ | 审计师写审计说明 → 做计算 → 粘贴证据 │ | ↓ │ | 提交经理复核 → 修改 → 再复核 │ | ↓ │ | 合伙人复核 → 修改 → 出报告 │ | │ | ───────────────────────────────── │ | │ | 风险导向工作流 │ | │ | 系统识别风险 → 项目经理确认风险清单 │ | ↓ │ | 系统自动采集证据 → 审计师确认证据充分性 │ | ↓ │ | 系统标记异常 → 审计师判断异常是否需要关注 │ | ↓ │ | 审计师执行追加程序如需→ 形成判断 │ | ↓ │ | 风险处理完毕 → 系统自动生成底稿 │ | ↓ │ | 经理复核风险处理质量 → 合伙人复核 │ | ↓ │ | 所有风险处理完毕 → 出报告 │ | │ --------------------------------------------------四、关键界面元素的设计原则原则一风险状态要一眼可见审计师最想知道的是当前项目有哪些风险、每个风险的状态是什么、哪些需要我处理。-------------------------------------------------- | 项目风险总览一眼可见 | -------------------------------------------------- | | | ┌──────────────────────────────────────────┐ │ | │ │ │ | │ 15个风险 10个正常 3个警告 2个紧急│ │ | │ ████ ████████ ██ ██ │ │ | │ │ │ | └──────────────────────────────────────────┘ │ | │ | 紧急需立即处理 │ | ├─ 收入确认截止性 → 点击查看 → 处理 │ | └─ 持续经营能力 → 点击查看 → 处理 │ | │ | 警告需关注 │ | ├─ 应收账款坏账准备 → 点击查看 │ | ├─ 存货跌价准备 → 点击查看 │ | └─ 关联方交易完整性 → 点击查看 │ | │ | 正常已处理 │ | └─ 点击查看全部... │ | │ --------------------------------------------------原则二证据要触手可及审计师处理风险的时候不应该需要去其他地方找证据。证据应该就在风险详情页面里想看就看。-------------------------------------------------- | 【证据区】 | -------------------------------------------------- | | | 与收入确认截止性相关的证据已自动关联 │ | │ | 销售合同 │ | ├─ 合同A-001 金额500万 签约日期12/28 │ | ├─ 合同A-002 金额300万 签约日期12/29 │ | └─ ... │ | [点击展开详情] [点击查看原件] │ | │ | 发货单 │ | ├─ 发货单B-001 发货日期12/28 物流单号... │ | └─ ... │ | [点击展开详情] │ | │ | 数据分析 │ | ├─ 12月各周收入分布图 │ | ├─ 与去年同期对比 │ | └─ 与行业平均对比 │ | [点击查看图表] │ | │ --------------------------------------------------原则三判断要有明确的输入和记录审计师做出判断的时候系统应该引导他提供判断的依据并自动记录判断的过程。-------------------------------------------------- | 【判断区】 | -------------------------------------------------- | | | 您对收入确认截止性风险的判断 │ | │ | □ 风险可控无需追加程序 │ | └─ 依据________________________________ │ | │ | □ 风险需要进一步调查 │ | └─ 追加程序 │ | □ 检查物流签收记录 │ | □ 访谈新增客户 │ | □ 执行截止测试 │ | □ 其他______________ │ | │ | □ 风险显著需要升级 │ | └─ 升级原因______________________________ │ | │ | 【自动记录】 │ | 判断人李四 │ | 判断时间2024-02-15 10:30 │ | 基于证据销售合同15份、发货单120份 │ | 系统异常标记3个 │ | │ --------------------------------------------------原则四底稿是自动生成的不是人工填写的当风险处理完毕系统自动生成底稿。底稿的内容来自风险描述引用的证据执行的程序审计师的判断系统自动记录的审计轨迹审计师只需要确认底稿内容是否准确不需要从零开始写。五、不同角色的界面差异审计平台不是只有一个用户群体。不同角色需要看到不同的信息。初级审计员视角-------------------------------------------------- | 我的工作 | -------------------------------------------------- | | | 今日任务由项目经理分配 │ | ├─ 获取XX公司12月物流签收记录 │ | ├─ 核对银行对账单与账面余额 │ | └─ 协助执行存货抽盘 │ | │ | 待我确认的风险处理 │ | ├─ 货币资金存在性 → 已获取证据待确认 │ | └─ 银行存款完整性 → 已核对待确认 │ | │ | 【知识推送】 │ | └─ 您正在处理货币资金科目推荐阅读 │ | 货币资金审计常见风险点 │ | │ --------------------------------------------------初级审计员需要的是明确的任务清单和操作指引。项目经理视角-------------------------------------------------- | 项目仪表板 | -------------------------------------------------- | │ | 项目整体风险状态 │ | ├─ 高风险3个1个待处理 │ | ├─ 中风险8个3个待复核 │ | └─ 低风险12个全部已处理 │ | │ | 团队工作负荷 │ | ├─ 李四5个风险处理中 │ | ├─ 王五3个风险处理中 │ | └─ 赵六2个风险处理中 │ | │ | 关键里程碑 │ | ├─ 收入确认截止性 → 预计本周完成 │ | └─ 持续经营判断 → 需合伙人参与 │ | │ | 系统预警 │ | ⚠ 项目进度滞后于计划预计延期3天 │ | │ --------------------------------------------------项目经理需要的是全局视图和进度把控。合伙人视角-------------------------------------------------- | 合伙人仪表板 | -------------------------------------------------- | │ | 我负责的所有项目 │ | ├─ 项目A风险等级中进度80%预计按期出具 │ | ├─ 项目B风险等级高存在收入确认重大异常 │ | └─ 项目C风险等级低进度滞后需关注 │ | │ | 需要我亲自参与的高风险判断 │ | └─ 项目B持续经营判断 → 点击查看 → 参与讨论 │ | │ | 监管关注要点自动汇总 │ | └─ 3个项目存在收入确认风险需重点关注 │ | │ | 全所风险热力图 │ | ├─ 收入确认 ████████ 全所高风险领域 │ | └─ 应收账款 ██████ 需关注 │ | │ --------------------------------------------------合伙人需要的是风险预警和决策支持。六、从底稿导向到风险导向的迁移路径如果你现在的审计系统已经是底稿编号导向的如何向风险导向转型不需要推倒重来可以分三步走。第一步增加风险聚合层1-2个月在现有底稿系统之上增加一个风险聚合层。不改变底稿的填写方式但从底稿内容中自动提取风险信息在首页展示风险仪表板。技术实现新增一个风险假设数据表写一个数据同步脚本定期从底稿中提取风险信息开发一个风险仪表板页面效果审计师既可以使用熟悉的底稿系统又能看到全局的风险视图。第二步改变工作入口1个月把系统的默认首页从底稿列表改成风险仪表板。审计师点击一个风险系统跳转到对应的底稿。关键工作习惯不需要大改但认知起点变了从我要填这张底稿变成我要处理这个风险。第三步重构底层数据模型6-12个月当团队逐渐适应了风险导向的工作方式后可以开始重构底层数据模型。把证据从底稿中解耦出来建立独立的证据池和风险模型。底稿变成风险处理完毕后的自动生成物。这个过程可能需要一到两年时间但每一步都能带来立即可见的效果不会因为等待完整重构而延误价值交付。七、写在最后的话审计平台的界面设计不是美术问题是认知问题。如果你认为审计师的工作是填底稿那你的系统首页就应该是底稿列表。如果你认为审计师的工作是管理风险那你的系统首页就应该是风险仪表板。界面是认知的外化。你界面上放什么就说明你认为什么最重要。做了这么多年审计系统我最深的体会是好的审计平台界面应该让审计师忘记底稿的存在。不是底稿消失了而是底稿退到了后台。审计师看到的是风险、是证据、是判断。底稿是风险处理完毕后的自然产出就像打完仗自动生成战报。从今天我要填哪张底稿到这个项目还有哪些风险需要处理这不只是界面设计的改变这是整个审计工作范式的改变。这个改变很难。因为整个行业几十年都是围绕底稿来工作的。但这个改变值得。因为审计的本质从来不是底稿是风险。文章声明本文仅供学习参考请勿用于商业用途。
09_AI审计平台设计：从风险识别出发而非从底稿编号出发
发布时间：2026/5/22 11:09:16
09 AI审计平台设计从风险识别出发而非从底稿编号出发摘要如果你打开一个审计系统首页显示的是E1000、E2000、E3000这些底稿编号那这个系统的设计者一定没搞明白审计师每天到底在想什么。我做了八年审计系统UX设计访谈过上百个审计师发现一个规律审计师早上睁开眼想的不是今天该填哪张底稿而是这个项目还有哪些雷没排完。这篇文章从用户体验的第一性原理出发讲清楚审计平台界面设计的核心逻辑——不是让界面更漂亮是让审计师更快找到该排的雷。文章标签审计平台设计AI审计用户体验审计系统审计底稿风险识别审计平台产品设计关键字审计平台设计, AI审计, 用户体验, 审计系统, 审计底稿, 风险识别, 审计平台, 产品设计, 审计数字化, 审计风险一、底稿编号导向的荒谬我见过一个审计系统登录后的首页是这样的-------------------------------------------------- | 某审计系统首页底稿编号导向 | -------------------------------------------------- | | | 欢迎使用XX审计系统 | | | | 我的待办15项未开始 | | ├─ E1000 货币资金底稿 │ | ├─ E2000 应收账款底稿 │ | ├─ E2100 坏账准备底稿 │ | ├─ E3000 存货底稿 │ | ├─ E3100 存货跌价准备底稿 │ | ├─ E4000 固定资产底稿 │ | └─ ... │ | | | 已完成的底稿23项 │ | 项目进度23/38 60% │ | | --------------------------------------------------这个设计有什么问题问题是审计师的工作不是填底稿是管理风险。当审计师看到E1000货币资金底稿的时候他脑子里想的是“哦今天要填货币资金底稿。”但正确的想法应该是“货币资金这个科目存在性和完整性风险处理得怎么样了证据够不够有没有异常”底稿编号导向的设计把审计师从风险管理者降级成了底稿填写员。更荒谬的是有些系统把底稿编号当成了导航的核心。审计师要找到一个风险点需要先记住这个风险点属于哪个底稿然后再去底稿列表里找。这就像医院的信息系统护士打开系统看到的是一个表单列表“体温记录表”“血压记录表”“用药记录表”——而不是3床病人今天有哪些异常指标需要关注。二、审计师的一天应该是怎样的让我们站在审计师的角度想想他一天的工作应该是怎样的。早上8:30打开系统底稿编号导向的系统系统提示您有15个底稿待完成今天建议完成E1000和E2000。审计师的想法“好吧打开E1000看看今天要填什么。”风险导向的系统-------------------------------------------------- | 今日风险提醒 | -------------------------------------------------- | | | 您负责的项目有3个高风险事项需要关注 | | | | [高] 收入确认截止性风险 | | 12月收入占全年35%远超行业平均20% │ | → 需要确认12月最后一周的发货是否真实 │ | → 建议追加程序获取物流签收记录 │ | │ | [中] 应收账款坏账准备 │ | 计提比例5%但历史回款率98%存在矛盾 │ | → 需要判断计提比例是否过高 │ | │ | [中] 存货跌价准备 │ | 系统已自动获取市场价格数据 │ | → 需要复核管理层估计的可变现净值 │ | │ | 【您今天的工作建议】 │ | 1. 优先处理收入确认截止性风险高风险 │ | 2. 联系客户获取12月最后一周的物流签收记录 │ | 3. 下午2点项目组会议讨论收入异常 │ | 4. 昨日未完成复核存货跌价准备测试底稿 │ | │ | 【昨日动态】 │ | ✅ 已完成货币资金存在性验证 │ | ✅ 已完成银行询证函回函核对23/25 │ | │ --------------------------------------------------审计师的想法“收入风险这么高了得赶紧处理。”两种设计的本质区别前者告诉审计师你要做什么后者告诉审计师你应该关注什么。上午10:00处理风险底稿编号导向的系统审计师打开E1000货币资金底稿按模板要求逐项填写。填到银行对账单核对这一栏打开附件里的银行对账单PDF人工核对数字。风险导向的系统审计师点击收入确认截止性风险系统展示-------------------------------------------------- | 风险收入确认截止性 | -------------------------------------------------- | | | 【风险等级】高 │ | 【涉及认定】截止、发生 │ | 【涉及科目】主营业务收入 │ | │ | 【为什么有这个风险】 │ | ├─ 准则要求CAS 14 第9条 │ | ├─ 系统识别12月收入占全年34.7% │ | ├─ 行业对比同行业12月平均占比18-22% │ | ├─ 历史对比去年12月占比25% │ | └─ 审计师备注年末突击确认收入的可能性 │ | │ | 【系统已采集的证据】 │ | ├─ 12月销售合同 15份 │ | ├─ 12月发货单 120份 │ | ├─ 12月发票 120张 │ | └─ 物流签收记录部分缺失 │ | │ | 【系统标记的异常】 │ | ⚠ 12月25日后的5笔发货单无物流签收记录 │ | ⚠ 3家12月新增大客户合同金额均超500万 │ | ⚠ 12月最后一周确认收入占12月总收入60% │ | │ | 【建议追加程序】 │ | 1. 获取缺失的物流签收记录 │ | 2. 访谈3家新增大客户 │ | 3. 检查期后退货情况 │ | │ | 【审计师判断】 │ | □ 异常可解释风险可控 │ | □ 异常需要进一步调查 │ | └─ 追加程序________________________ │ | │ --------------------------------------------------审计师的工作是查看系统整理好的证据和异常判断是否需要追加程序形成结论。不是打开空白底稿模板从零开始收集和整理证据。下午3:00经理复核底稿编号导向的系统经理打开审计师填好的E1000逐行检查数字对不对、格式规不规范、签字齐不齐。风险导向的系统经理打开项目风险仪表板看到-------------------------------------------------- | 项目风险状态 - 复核视图 | -------------------------------------------------- | | | 项目经理张三 │ | 待复核风险处理5个 │ | │ | ┌──────────────────────────────────────┐ │ | │ ✅ 货币资金存在性 │ │ | │ 状态已确认 审计师李四 │ │ | │ 结论证据充分无异常 │ │ | │ 一键复核 │ │ | └──────────────────────────────────────┘ │ | │ | ┌──────────────────────────────────────┐ │ | │ ⚠ 收入确认截止性高风险 │ │ | │ 状态待复核 审计师李四 │ │ | │ 结论异常需调查已追加4项程序 │ │ | │ 点击查看详情 → │ │ | │ │ │ | │ 【追加程序执行情况】 │ │ | │ 1. ✓ 已获取5份缺失物流记录 │ │ | │ 2. ✓ 已访谈3家新增客户 │ │ | │ 3. ✓ 期后退货3笔金额120万 │ │ | │ 4. ○ 截止测试中2笔收入确认时点存疑 │ │ | │ │ │ | │ 【经理复核意见】 │ │ | │ □ 同意审计师结论 │ │ | │ □ 需要补充请说明_____________ │ │ | │ □ 需要升级至合伙人 │ │ | └──────────────────────────────────────┘ │ | │ | 关键指标 │ | ├─ 高风险风险处理率60% │ | ├─ 证据充分率75% │ | └─ 异常待处理2个 │ | │ --------------------------------------------------经理的复核逻辑变了不是检查底稿填没填对而是检查风险处理得是否充分、判断是否合理。三、从底稿编号到风险识别的设计转变要实现从底稿编号导向到风险导向的设计转变需要在三个层面做出改变第一层信息架构的重构-------------------------------------------------- | 信息架构对比 | -------------------------------------------------- | | | 底稿编号导向的信息架构 │ | ├─ 项目 │ | │ ├─ 底稿 E1000 货币资金 │ | │ ├─ 底稿 E2000 应收账款 │ | │ ├─ 底稿 E3000 存货 │ | │ └─ ... │ | │ 风险信息分散在各底稿中 │ | │ | 风险导向的信息架构 │ | ├─ 项目 │ | │ ├─ 风险假设 │ | │ │ ├─ 货币资金存在性 │ | │ │ ├─ 应收账款可收回性 │ | │ │ ├─ 收入确认截止性 │ | │ │ └─ ... │ | │ ├─ 证据池 │ | │ ├─ 判断记录 │ | │ └─ 底稿视图按需生成 │ | │ 风险是中心底稿是视图 │ | │ --------------------------------------------------第二层界面设计的重构底稿编号导向的界面逻辑打开底稿 → 填写内容 → 保存 → 提交复核 ↑_____________________________| 循环往复底稿是工作的中心风险导向的界面逻辑查看风险 → 查看证据 → 做判断 → 确认风险处理完毕 ↑______________________________________| ↓ 自动生成对应底稿第三层工作流的重构-------------------------------------------------- | 工作流对比 | -------------------------------------------------- | | | 传统工作流底稿驱动 │ | │ | 项目经理分配底稿 → 审计师填写底稿 │ | ↓ │ | 审计师向客户要资料 → 整理数据 → 填入底稿 │ | ↓ │ | 审计师写审计说明 → 做计算 → 粘贴证据 │ | ↓ │ | 提交经理复核 → 修改 → 再复核 │ | ↓ │ | 合伙人复核 → 修改 → 出报告 │ | │ | ───────────────────────────────── │ | │ | 风险导向工作流 │ | │ | 系统识别风险 → 项目经理确认风险清单 │ | ↓ │ | 系统自动采集证据 → 审计师确认证据充分性 │ | ↓ │ | 系统标记异常 → 审计师判断异常是否需要关注 │ | ↓ │ | 审计师执行追加程序如需→ 形成判断 │ | ↓ │ | 风险处理完毕 → 系统自动生成底稿 │ | ↓ │ | 经理复核风险处理质量 → 合伙人复核 │ | ↓ │ | 所有风险处理完毕 → 出报告 │ | │ --------------------------------------------------四、关键界面元素的设计原则原则一风险状态要一眼可见审计师最想知道的是当前项目有哪些风险、每个风险的状态是什么、哪些需要我处理。-------------------------------------------------- | 项目风险总览一眼可见 | -------------------------------------------------- | | | ┌──────────────────────────────────────────┐ │ | │ │ │ | │ 15个风险 10个正常 3个警告 2个紧急│ │ | │ ████ ████████ ██ ██ │ │ | │ │ │ | └──────────────────────────────────────────┘ │ | │ | 紧急需立即处理 │ | ├─ 收入确认截止性 → 点击查看 → 处理 │ | └─ 持续经营能力 → 点击查看 → 处理 │ | │ | 警告需关注 │ | ├─ 应收账款坏账准备 → 点击查看 │ | ├─ 存货跌价准备 → 点击查看 │ | └─ 关联方交易完整性 → 点击查看 │ | │ | 正常已处理 │ | └─ 点击查看全部... │ | │ --------------------------------------------------原则二证据要触手可及审计师处理风险的时候不应该需要去其他地方找证据。证据应该就在风险详情页面里想看就看。-------------------------------------------------- | 【证据区】 | -------------------------------------------------- | | | 与收入确认截止性相关的证据已自动关联 │ | │ | 销售合同 │ | ├─ 合同A-001 金额500万 签约日期12/28 │ | ├─ 合同A-002 金额300万 签约日期12/29 │ | └─ ... │ | [点击展开详情] [点击查看原件] │ | │ | 发货单 │ | ├─ 发货单B-001 发货日期12/28 物流单号... │ | └─ ... │ | [点击展开详情] │ | │ | 数据分析 │ | ├─ 12月各周收入分布图 │ | ├─ 与去年同期对比 │ | └─ 与行业平均对比 │ | [点击查看图表] │ | │ --------------------------------------------------原则三判断要有明确的输入和记录审计师做出判断的时候系统应该引导他提供判断的依据并自动记录判断的过程。-------------------------------------------------- | 【判断区】 | -------------------------------------------------- | | | 您对收入确认截止性风险的判断 │ | │ | □ 风险可控无需追加程序 │ | └─ 依据________________________________ │ | │ | □ 风险需要进一步调查 │ | └─ 追加程序 │ | □ 检查物流签收记录 │ | □ 访谈新增客户 │ | □ 执行截止测试 │ | □ 其他______________ │ | │ | □ 风险显著需要升级 │ | └─ 升级原因______________________________ │ | │ | 【自动记录】 │ | 判断人李四 │ | 判断时间2024-02-15 10:30 │ | 基于证据销售合同15份、发货单120份 │ | 系统异常标记3个 │ | │ --------------------------------------------------原则四底稿是自动生成的不是人工填写的当风险处理完毕系统自动生成底稿。底稿的内容来自风险描述引用的证据执行的程序审计师的判断系统自动记录的审计轨迹审计师只需要确认底稿内容是否准确不需要从零开始写。五、不同角色的界面差异审计平台不是只有一个用户群体。不同角色需要看到不同的信息。初级审计员视角-------------------------------------------------- | 我的工作 | -------------------------------------------------- | | | 今日任务由项目经理分配 │ | ├─ 获取XX公司12月物流签收记录 │ | ├─ 核对银行对账单与账面余额 │ | └─ 协助执行存货抽盘 │ | │ | 待我确认的风险处理 │ | ├─ 货币资金存在性 → 已获取证据待确认 │ | └─ 银行存款完整性 → 已核对待确认 │ | │ | 【知识推送】 │ | └─ 您正在处理货币资金科目推荐阅读 │ | 货币资金审计常见风险点 │ | │ --------------------------------------------------初级审计员需要的是明确的任务清单和操作指引。项目经理视角-------------------------------------------------- | 项目仪表板 | -------------------------------------------------- | │ | 项目整体风险状态 │ | ├─ 高风险3个1个待处理 │ | ├─ 中风险8个3个待复核 │ | └─ 低风险12个全部已处理 │ | │ | 团队工作负荷 │ | ├─ 李四5个风险处理中 │ | ├─ 王五3个风险处理中 │ | └─ 赵六2个风险处理中 │ | │ | 关键里程碑 │ | ├─ 收入确认截止性 → 预计本周完成 │ | └─ 持续经营判断 → 需合伙人参与 │ | │ | 系统预警 │ | ⚠ 项目进度滞后于计划预计延期3天 │ | │ --------------------------------------------------项目经理需要的是全局视图和进度把控。合伙人视角-------------------------------------------------- | 合伙人仪表板 | -------------------------------------------------- | │ | 我负责的所有项目 │ | ├─ 项目A风险等级中进度80%预计按期出具 │ | ├─ 项目B风险等级高存在收入确认重大异常 │ | └─ 项目C风险等级低进度滞后需关注 │ | │ | 需要我亲自参与的高风险判断 │ | └─ 项目B持续经营判断 → 点击查看 → 参与讨论 │ | │ | 监管关注要点自动汇总 │ | └─ 3个项目存在收入确认风险需重点关注 │ | │ | 全所风险热力图 │ | ├─ 收入确认 ████████ 全所高风险领域 │ | └─ 应收账款 ██████ 需关注 │ | │ --------------------------------------------------合伙人需要的是风险预警和决策支持。六、从底稿导向到风险导向的迁移路径如果你现在的审计系统已经是底稿编号导向的如何向风险导向转型不需要推倒重来可以分三步走。第一步增加风险聚合层1-2个月在现有底稿系统之上增加一个风险聚合层。不改变底稿的填写方式但从底稿内容中自动提取风险信息在首页展示风险仪表板。技术实现新增一个风险假设数据表写一个数据同步脚本定期从底稿中提取风险信息开发一个风险仪表板页面效果审计师既可以使用熟悉的底稿系统又能看到全局的风险视图。第二步改变工作入口1个月把系统的默认首页从底稿列表改成风险仪表板。审计师点击一个风险系统跳转到对应的底稿。关键工作习惯不需要大改但认知起点变了从我要填这张底稿变成我要处理这个风险。第三步重构底层数据模型6-12个月当团队逐渐适应了风险导向的工作方式后可以开始重构底层数据模型。把证据从底稿中解耦出来建立独立的证据池和风险模型。底稿变成风险处理完毕后的自动生成物。这个过程可能需要一到两年时间但每一步都能带来立即可见的效果不会因为等待完整重构而延误价值交付。七、写在最后的话审计平台的界面设计不是美术问题是认知问题。如果你认为审计师的工作是填底稿那你的系统首页就应该是底稿列表。如果你认为审计师的工作是管理风险那你的系统首页就应该是风险仪表板。界面是认知的外化。你界面上放什么就说明你认为什么最重要。做了这么多年审计系统我最深的体会是好的审计平台界面应该让审计师忘记底稿的存在。不是底稿消失了而是底稿退到了后台。审计师看到的是风险、是证据、是判断。底稿是风险处理完毕后的自然产出就像打完仗自动生成战报。从今天我要填哪张底稿到这个项目还有哪些风险需要处理这不只是界面设计的改变这是整个审计工作范式的改变。这个改变很难。因为整个行业几十年都是围绕底稿来工作的。但这个改变值得。因为审计的本质从来不是底稿是风险。文章声明本文仅供学习参考请勿用于商业用途。
 中 userdata 参数的正确用法与内存管理)
