建设银行数字化转型与内部控制能力形成调查问卷
本问卷用于了解建设银行数字化转型过程中,数字技术如何进入组织责任、业务流程、风险控制、整改与持续监督。问卷采用选择题为主、开放题为辅的半结构化设计,重点获得可核对的过程信息。涉及客户信息、商业秘密、模型参数或内部敏感信息无需提供。
1. 您主要在哪一层级或机构工作或曾工作
总行
一级分行
二级分行或省辖分行
支行或基层经营机构
其他(请说明)
2. 您在建设银行或相关岗位的工作年限大约为多少
3年以下
3至5年
6至10年
11至15年
15年以上
3. 您与本次所述数字化项目或流程的关系最接近以下哪一种
项目牵头或核心负责人
直接参与设计或建设或管理
直接使用或执行相关流程
负责检查或评价或审计
主要通过协同工作直接了解
其他(请说明)
4. 您直接参与或持续接触过哪些类型的工作
数字化转型或金融科技
数据治理或数据平台
授信审批或信贷风险
反洗钱或反欺诈或风险预警
客户信息保护或数据安全或数据共享
合规管理或内控评价或整改
系统建设或模型或规则管理
内部审计或监督检查
其他(请说明)
5. 请选取一个您本人亲自参与或直接了解最深的数字化项目、业务流程或控制事项,并简要说明其背景、时间和您的职责
6. 请选择最符合您在上述项目或流程中主要角色的身份
风险管理人员
业务条线人员
科技或数据人员
合规或内控人员
内部审计人员
管理层或战略或数字化管理人员
7. 在该项目或流程中,风险管理部门承担的主要角色是什么
牵头制定风险要求并统筹推进
共同参与规则设计和审核
主要负责风险复核或审批
主要负责监测、预警或后续处置
主要配合其他部门
其他(请说明)
不了解或不适用
8. 推动该项目或流程启动或调整的主要原因有哪些
监管或政策要求
集团或上级行数字化战略
业务效率或客户体验需求
既有风险事件或问题暴露
内部检查或审计发现
技术平台升级带来的机会
业务规模扩大或复杂度上升
其他(请说明)
不了解
9. 风险规则进入系统前,通常会经过哪些环节
风险部门提出业务规则
业务部门确认场景需求
科技部门进行技术实现
独立验证或测试
合规或内控审核
管理层或授权主体审批
上线后试运行或监测
无固定程序
其他(请说明)
不了解
10. 系统识别出风险后,通常采取哪些处理方式
自动提示
自动风险分级
自动拦截或拒绝
转人工复核
要求补充材料
升级主管或更高层级审批
进入事后监测或名单管理
其他(请说明)
不了解
11. 当人工判断与系统结果不一致时,最常见的处理方式是什么
原则上不得人工覆盖
可人工覆盖,但必须说明理由并留痕
可申请例外,需主管或风险部门审批
可由特定授权岗位直接调整
实际操作较灵活,无统一规则
其他(请说明)
不了解或未遇到
12. 数字化运行中新风险或控制缺陷通常通过哪些渠道被发现
系统日志或监测预警
风险部门日常监测
业务人员反馈
合规或内控检查
内部审计
监管检查
客户投诉或外部事件
模型表现监测
其他(请说明)
不了解
13. 问题发现后,通常会采取哪些整改措施
建立整改台账并明确责任人
修改风险规则或模型
调整系统权限或强制控制
修订制度或流程
增加人工复核或审批节点
开展同类业务排查
由相对独立主体复测验收
持续监测整改效果
仅口头提示或培训
其他(请说明)
不了解
14. 相关风险控制在跨年度运行中的状态最接近哪一种
基本成为固定制度和系统流程,人员变化后仍持续执行
持续运行,但仍经常依赖关键人员推动
主要以阶段性专项方式运行
后续变化较大,难以判断是否稳定
项目结束后作用明显减弱
其他(请说明)
不了解
15. 请用一个具体例子说明:一笔业务或一个风险事项从系统识别到最终处理,大致经历了哪些关键步骤
16. 请举例说明一次系统判断与人工判断不一致或系统规则不适配实际业务的情况,以及后来如何处理
17. 请举例说明一次数字化运行中新风险或控制问题如何被发现,并进一步推动规则、系统或流程发生变化
18. 从您的实际经历看,数字化工具要真正转化为稳定的风险控制能力,最关键的条件是什么
19. 在数字化系统或工具上线前,这项业务主要依靠哪些方式办理和控制风险
人工经验判断
纸质或线下审批
多个系统分别查询
人工核对客户或交易资料
层级签字授权
已有部分系统自动控制
其他(请说明)
不了解或加入时系统已上线
20. 系统上线后,您感受到的主要变化有哪些
信息查询更集中
自动识别或预警增加
人工审批环节减少
强制校验或拦截增加
审批层级或权限调整
操作留痕更完整
工作效率提高
操作步骤反而增加
其他(请说明)
变化不明显
21. 系统发现异常或风险时,其约束程度最接近哪一种
仅提示,不影响继续操作
提示后需人工确认
特定情形强制拦截
大部分高风险事项强制拦截并转审批
不同业务差异较大
其他(请说明)
不了解
22. 遇到系统拦截或风险提示时,实际业务通常怎么处理
补充材料后重新提交
转风险或合规人员复核
提交主管审批
申请例外授权
修改业务方案后再办理
直接终止业务
通过其他流程处理
其他(请说明)
未遇到
23. 在您接触的流程中,人工能否绕过或覆盖系统判断
基本不能
可以,但必须按正式例外流程审批并留痕
部分岗位有特定授权权限
现实中存在非标准替代路径
不同业务差异较大
其他(请说明)
不了解
24. 风险或合规规则发生变化时,一线通常通过哪些方式感知
系统直接修改,操作步骤发生变化
收到制度或通知
参加培训
新增审批或材料要求
风险提示或拦截阈值变化
由主管或管理人员口头传达
通常不明显
其他(请说明)
25. 您认为数字化控制在实际业务中最主要的作用是什么
减少人工差错
提高风险识别速度
提高控制覆盖范围
增强强制执行
增加全过程留痕和责任追溯
提高效率或缩短审批时间
主要是信息辅助,控制作用有限
其他(请说明)
26. 如果某项数字化控制效果不理想,最常见的原因有哪些
数据质量或数据不完整
系统规则与业务实际不匹配
系统只提示但不强制
人工仍可轻易绕开
流程过于复杂导致抵触
跨部门协调不足
模型或规则更新不及时
培训和理解不足
其他(请说明)
未遇到明显问题
27. 请描述一笔您亲自处理过的业务:系统在哪些节点自动判断,哪些节点需要人工处理,最后如何完成决策
28. 请举例说明一次系统判断与您的业务经验不一致的情况,以及最后是如何处理的
29. 如果您遇到过系统功能上线后实际作用有限、使用率低或给业务增加额外负担的情况,请说明原因和后续变化
30. 从一线业务角度看,什么样的数字化控制才算真正管得住、用得上、能持续
31. 您所参与项目的需求主要来自哪些主体
业务条线
风险管理部门
合规或内控部门
管理层或战略部门
监管要求
科技或数据部门主动提出
内部审计或检查整改
其他(请说明)
32. 业务或风险要求转化为系统规则时,通常经过哪些环节
需求澄清或业务规则定义
数据口径确认
技术方案设计
跨部门评审
开发与测试
业务验收
风险或合规验证
上线审批
其他(请说明)
无固定流程
33. 统一平台、数据中台或公共组件在控制流程中主要提供哪些能力
统一客户或数据口径
身份认证
权限校验
风险规则调用
模型评分
外部数据接入
日志记录或审计追踪
数据脱敏或安全控制
其他(请说明)
不涉及
34. 新规则或模型上线前的验证方式最接近哪一种
主要由开发团队自测
开发测试与业务验收
开发测试、业务验收与风险或合规确认
存在相对独立验证或测试主体
不同项目差异较大
其他(请说明)
不了解
35. 系统是否保留人工干预或例外授权入口
原则上不允许人工覆盖
允许,但须正式审批并记录理由
仅特定授权岗位可操作
技术上可操作但管理规则不统一
不同场景不同
其他(请说明)
不了解或不涉及
36. 系统对规则执行和人工操作通常保留哪些记录
数据调用记录
规则或模型判断结果
操作人员与时间
人工复核意见
例外理由及审批
系统版本或规则版本
最终处理结果
后续复核记录
其他(请说明)
记录不完整或不了解
37. 运行中发现缺陷或风险后,规则或系统变更通常经过哪些环节
登记问题或工单
确认责任主体
分析原因
修改规则或代码
重新测试或验证
业务、风险或合规验收
正式发布或版本管理
上线后持续监测
其他(请说明)
无固定流程
38. 科技整改完成后的验收方式最接近哪一种
开发团队自行确认即可
由需求提出部门验收
由业务与风险或合规共同验收
由相对独立测试或验证主体复测
不同项目差异较大
其他(请说明)
不了解
39. 请选一个具体控制功能,说明它如何从业务或风险需求一步步变成最终上线的系统规则
40. 请举例说明一次数据口径、接口、权限或平台能力不足导致控制效果受影响的情况,以及如何解决
41. 请举例说明一次系统上线后发现问题并进行规则或程序变更的完整过程
42. 从技术与数据角度看,一个平台什么时候才不只是技术系统,而真正成为稳定的控制基础设施
43. 数字化流程中的合规或内控问题通常通过哪些渠道被发现
系统监测或预警
业务自查
风险部门监测
合规或内控专项检查
内部审计
监管检查
客户投诉或外部事件
数据或模型异常
其他(请说明)
44. 问题被确认后,通常会形成哪些正式整改安排
整改台账
责任部门或责任人
整改期限
整改措施清单
升级汇报或专项会议
复测或验收要求
持续跟踪直至关闭
其他(请说明)
不一定形成正式安排
45. 整改措施通常涉及哪些层面
制度修订
业务流程调整
系统规则修改
权限调整
模型或算法调整
增加人工复核或审批
培训与提示
同类业务排查
持续监测
其他(请说明)
46. 整改完成后,由谁确认问题可以关闭
整改部门自行确认
合规或内控部门复核
风险部门复核
内部审计复核
多个部门联合验收
视问题类型而定
其他(请说明)
不了解
47. 某一业务发现问题后,同类排查一般会扩展到什么范围
仅处理当前事项
同一部门或同一流程
同一系统或同类业务
分行范围
全行或多个条线
视风险等级决定
其他(请说明)
不了解
48. 制度要求转化为系统控制的程度最接近哪一种
多数仍依赖人工理解和执行
关键要求会转化为系统提示
重要高风险要求会转化为权限、拦截或强制流程
大部分可系统化要求已嵌入系统
不同业务差异很大
其他(请说明)
不了解
49. 制度与系统规则不一致时,通常如何处理
先按最新制度人工控制
优先紧急修改系统
临时增加人工复核或审批
暂停相关业务或功能
形成问题工单并限期整改
由管理层协调决定
其他(请说明)
未遇到
50. 整改关闭后通常如何持续监督
系统日志持续监测
定期内控或合规检查
年度复核
模型或规则定期复评
内部审计跟踪
指标或报表监测
无固定后续监测
其他(请说明)
51. 请举一个具体案例说明:数字化运行中发现的问题是如何从问题识别一步步变成制度、流程或系统规则调整的
52. 请说明一次需要把文字制度要求真正转化为系统强制控制的情形,为什么必须系统化
53. 请举例说明一次业务、科技、风险或合规之间对整改方式存在分歧的情况,以及最终如何协调
54. 从合规或内控角度看,什么情况下才能认为一项数字化控制已经从专项整改变成日常稳定内控
55. 审计数字化业务或系统控制时,通常会重点检查哪些证据
制度或流程文件
系统配置或权限
系统日志或操作记录
抽样业务记录
模型或规则验证材料
例外审批记录
整改台账
访谈或现场测试
其他(请说明)
56. 判断一项系统控制设计有效时,最重要的依据有哪些
职责和权限清晰
控制规则与风险相匹配
系统能够强制执行
存在必要的人工复核或授权
全过程可留痕追溯
规则或模型经过验证
异常有处理机制
其他(请说明)
57. 判断一项系统控制运行有效时,通常采用哪些方式
检查系统日志
穿行测试
业务样本抽查
重新执行或复核
访谈操作人员
查看例外和异常记录
观察整改后运行情况
其他(请说明)
58. 对于人工覆盖或例外授权,审计通常重点关注什么
是否有明确授权范围
是否说明例外理由
是否提供支持材料
是否经过审批
是否系统留痕
是否存在频繁例外
是否进行事后复核
其他(请说明)
59. 审计发现数字化控制缺陷后,整改关闭通常需要满足哪些条件
完成制度或流程修订
完成系统规则或权限修改
提供测试或验证结果
由相关部门复核
完成同类排查
观察一段时间持续运行
提供责任和期限完成证明
其他(请说明)
60. 整改复核最常见的方式是什么
被审计单位自行报告整改完成
审计部门书面复核材料
审计部门现场或系统复测
由合规或风险等其他部门共同复核
视风险等级决定
其他(请说明)
不了解
61. 跨年度重复出现同类问题的情况,最常见的原因有哪些
只改制度未改系统
系统改了但执行不到位
权限或例外管理不足
数据或模型问题未根治
人员变化或培训不足
跨部门责任不清
整改范围过窄
未持续监测
其他(请说明)
未见明显重复问题
62. 从审计视角看,数字化控制跨期持续性的状态最接近哪一种
多数关键控制已制度化并可持续验证
关键控制能持续,但部分依赖人工和关键人员
不同业务差异较大
专项整改后容易弱化
目前证据不足以判断
其他(请说明)
63. 请举一个审计中能够说明系统有功能但控制未真正有效运行的具体例子
64. 请举一个整改后通过复测、后续审计或跨年度检查确认控制得到改善的例子
65. 如果某个负责人或关键人员发生变化,审计会通过哪些证据判断该控制仍能稳定运行,请结合实际说明
66. 从审计视角看,一个数字化工具要真正成为内部控制能力,至少需要具备哪些条件
67. 推动本轮数字化项目或转型的主要驱动因素有哪些
监管或政策要求
集团战略与管理层主动推动
业务增长与竞争压力
风险管理和合规需要
客户体验和效率需求
技术平台升级
既有问题或风险事件
其他(请说明)
68. 数字化议题通常通过哪些治理渠道进入正式管理程序
董事会或高级管理层会议
专业委员会
年度行动方案
专项工作组或项目组
预算与资源配置程序
绩效考核或任务清单
制度审议
其他(请说明)
69. 战略要求落实到具体部门时,主要通过哪些方式实现
明确牵头部门
明确协同部门
任务清单和责任人
专项预算或人员配置
时间节点或里程碑
考核指标
系统权限或岗位职责调整
其他(请说明)
70. 数字化项目资源优先级通常依据哪些因素决定
监管或合规刚性要求
风险重要性
业务价值或客户影响
投入产出或效率
技术可行性
全行复用价值
问题紧迫程度
战略重要性
其他(请说明)
71. 业务、风险、科技、合规发生分歧时,最常见的协调机制是什么
牵头部门协调解决
专业委员会或项目治理机制协调
管理层最终决策
以风险或合规底线为优先
以业务需求和可实现性综合平衡
不同事项差异较大
其他(请说明)
不了解
72. 项目上线后,管理层通常关注哪些指标或信息
使用率或覆盖率
效率和成本
业务增长或客户体验
风险识别或损失指标
异常或例外情况
合规或内控问题
系统稳定性
整改和持续运行
其他(请说明)
73. 运行中新风险或问题通常如何反馈到治理层
日常风险或合规报告
专项检查报告
项目例会或委员会
重大事项升级报告
内部审计报告
监管反馈
数据或模型监测报告
其他(请说明)
74. 一项数字化成果要从项目转为常态管理能力,通常需要哪些条件
进入正式制度
责任主体长期明确
嵌入系统和业务流程
形成稳定数据或平台支撑
有持续监测和评价
规则或模型定期更新
人员变化后仍可运行
纳入预算、考核或治理程序
其他(请说明)
75. 请举一个具体例子说明:某项监管或战略要求如何一步步转化为部门责任、系统或流程安排和实际控制
76. 请举例说明一次业务效率、风险审慎、科技可实现性或合规要求之间存在冲突的情况,最终如何权衡
77. 如果您接触过投入不少、系统也上线但管理或控制效果没有达到预期的项目,请说明原因
78. 如果让您概括数字技术真正转化为内部控制能力需要经历的关键步骤,您会如何概括
79. 您认为本次回答主要基于哪种信息来源
本人直接参与和亲历为主
本人直接参与并辅以同事或材料补充
主要来自工作中直接观察
主要来自内部材料或会议了解
其他(请说明)
80. 如研究者后续仅就非敏感流程细节进行一次补充核实,您是否愿意接受联系
愿意
视具体问题而定
不方便
81. 除了前述问题,您认为建设银行数字化转型影响内部控制还有哪些重要问题没有被问到
82. 如本问卷中有需要特别匿名、概括化处理或不宜引用的内容,请在此说明,也可补充其他备注
关闭
更多问卷
复制此问卷